2014-05-05 22:10 GMT+02:00 Kenneth Mastro <[email protected]>:
> 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
