Re: [libmicrohttpd] Stuck Single Threaded

[Christian Grothoff]

On 05/05/2014 10:10 PM, Kenneth Mastro wrote:
> First, great library!  Thanks for creating it!
> 
> Using microhttpd, I created a reasonably well performing webserver for
> an embedded system I'm working on.  Everything has been going well, but
> I'm stuck on something.
> 
> I've been trying to add a 'Comet' feature to the library where
> long-polling can be done.  In short, during the default URI handler
> callback (provided as args 5&6 to the start_daemon setup call), I
> ultimately 'wait' for the server to produce a message to send back to
> the client.  I.e., the long-poll.  If there are no messages after a
> while (e.g., a minute), I return an empty message back to the client and
> force it to ask again.
> 
> The problem I'm having is that this seems to prevent the daemon from
> processing any other incoming connections - regardless of my threading
> model.  I had assumed that 'select + thread pool' or 'one thread per
> connection' would allow what I'm doing to work, but it doesn't - it just
> sits and waits for the long-poll to time out (or send a valid message)
> before servicing the next client request.
> 
> This isn't the behavior I expected - particularly for the 'one thread
> per connection' mode.
> 
> Should I be doing this a different way?  I don't quite see how, but is
> this main callback the wrong place to do something like this?  Is my
> webserver structurally flawed in that I generate the content in that
> callback thread, in general?
> 
> As a side note, I haven't played with the 'suspend/resume' option, yet -
> but it seems like that shouldn't be necessary (or valid/appropriate) for
> 'one thread per connection' mode.
> 
> In short - how should I use the library to hold onto a request for an
> extended period of time as it prepares an answer while still allowing it
> to service other requests?

That is usually not an issue; however, if you set a limit on the
number of parallel connections MHD is allowed to serve, then 'holding'
one request may prevent MHD from accepting additional requests.  So
check that you didn't limit the requests (overall) or by IP address.

Note that you can do long polling even with the other threading modes,
but those might be more complicated to use (you'll need to use stuff
like MHD_connection_suspend and returning '0' from the content reader
callback.

As to the structure of your webserver, MHD deliberately offers you
various ways to generate the reply and organize your web server;
using the thread-per-connection method is not the most scalable
method, but not per-se bad --- I don't know your application, so
I cannot say if your webserver is 'flawed'.  What I can say is that
yes, you should be able to do a 'Comet' feature this way with MHD in
principle.


I hope this helps!

Happy hacking!

Christian

0x48426C7E.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature