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