Re: [libmicrohttpd] single-threaded daemon, multiple pending requests, responses batched

[Christian Grothoff]

On 04/13/2016 05:51 PM, Frank Ch. Eigler wrote:
> 
> Christian Grothoff wrote:
> 
>> [...]
>> Are you, by chance, doing significant blocking operations within the
>> single-threaded event loop? (Outch...). I understand that then our extra
>> run through select() might be, eh, "annoying", but the big issue is your
>> blocking behavior in a single threaded server.
> 
> Yes, I admitted as much, perhaps in too many words!  Indeed there are
> significant blocking operations in a single-threaded event loop, which
> is admittedly imperfect.  (You can reproduce it by changing your
> single-threaded demo program to sleep(4) before returning MHD_YES from
> the connection callback.)
> 
>> Anyway, we could probably do something about this (reducing your pain,
>> but not solving the main problem). I'm thinking of something along the
>> lines of the attached patch.  It MAY help, but ONLY if you're using
>> epoll() and TURBO mode, so you must pass both:
>>  MHD_USE_EPOLL_LINUX_ONLY | MHD_USE_EPOLL_TURBO
> 
> Thanks!  I tested the patch (with the "0 ==" typo fixed to "0 !=").
> It helped some, confirmed both by firefox/firebug and server-side
> strace.  What happens with the new code is that one response object
> does get transmitted right away.  Unfortunately, that's only the
> 160ish bytes of HTTP response headers, and not the response body.  (An
> amateurish loop rerunning the write_handler a few times didn't help.)

Yeah, the 'idle' handler needs to run in the middle to 'prepare' more
data for transmission.

Anyway, this is useful as it shows that the proposed fix would only be
partial.

I hear Evgeny wants to hack up a more complete solution, so this should
point him in the right direction ;-).

0xE29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature