[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Frank Ch. Eigler
Subject: Re: [libmicrohttpd] single-threaded daemon, multiple pending requests, responses batched
Date: Wed, 13 Apr 2016 10:50:47 -0400
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

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:

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.)

- FChE

reply via email to

[Prev in Thread] Current Thread [Next in Thread]