Re: [libmicrohttpd] Stuck Single Threaded

[Lorenzo Miniero]

2014-05-05 22:10 GMT+02:00 Kenneth Mastro <address@hidden>:

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?

I'm using version 0.9.34 of microhttpd on Linux.

Thanks much,
Ken

Hi Kenneth,

I'm just a user of the library like you so no developer here, but I am using it as you'd like to in my project, and it works great, tons of parallel requests being handled and no issue. I use the "one thread per connection" flag, for long polls I wait until I have data to provide (or reply when a timeout fires) and I do generate all the content in the callback thread, so I'm not sure what you may be doing wrong. Unlike you, I'm using poll instead of select, but I seem to recall testing select as well just fine.

If it can help, this is where I use the library:

https://github.com/meetecho/janus-gateway/blob/master/janus.c

just look for janus_ws_handler which is the request callback. Whenever a long poll is involved (a GET) a separate function, janus_ws_notifier, is invoked by the callback as a helper, but still within the same thread that originated the call to the callback function in the first place.

Cheers,

Lorenzo