bug#49897: 28.0.50; [PATCH] Make sense of url-retrieve-synchronously

[Lars Ingebrigtsen <larsi@gnus.org>]

dick <dick.r.chiang@gmail.com> writes:

> I'm sorry to say the rewrite doesn't solve bug#49861 (hanging http GETs) for
> me.  The process filter `url-http-generic-filter` just isn't seeing any data
> from the remote site, and given the frequency of occurrence, it's not the
> remote site's fault.  There's something off about the C-level network
> descriptor handling for process filters.

Yes, people have been poking away at the process.c code again and again
to try to fix these hangs, and they usually seem to be able to fix their
own use case...  it's pretty maddening.  It's always impossible for
anybody else to reproduce the problems, which doesn't help.

It's not that network connections are complex in themselves, but the
Emacs process stuff has grown from a viewpoint of "run a command and
output the data in the displayed buffer", and that's grown into real
network connections, with coding systems applied and filters and...

(And then TLS was added, and then there was that rewrite to make it all
asynchronous, which complicated things even further.)

So what we have is a slow, convoluted mess in this area, which is a
shame.

I have for years wanted to redo the network stuff (note -- note the
process stuff; they're separate issues) to be efficient and sane.  That
is: You can push octets to the network, and you get octets back, stashed
into a unibyte buffer only.  And then it's up to the application level,
not the network level, to interpret the octets.

But it's that problem of finding the time...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no