Re: [libmicrohttpd] Clarification on receiving on one thread, replying on another

[Tom Cornell]

On Mon, Oct 24, 2016 at 08:22:03PM +0200, Christian Grothoff wrote:
> On 10/24/2016 04:51 PM, Tom Cornell wrote:
> > Quick question, probably: Should I be able to send replies from a
> > different thread from the one that runs the access handler callback,
> > using internal select? (Using suspend/resume. Also this is 0.9.50, in
> > case that matters.)
> 
> You may call resume from a different thread, but you must then queue the
> reply from the MHD thread.
> 
> > I am getting a panic from the very end of build_header_response (I
> > think line 1123 in 0.9.50). From my own logs (and custom panic
> > function), it looks like mhd_panic is called by the main listener
> > thread, pretty much right after my worker thread has sent the
> > response. Usually, things (appear to) work fine for a few minutes
> > before the panic, but I am assuming that is more a matter of luck
> > than design.
> > 
> > I know I could be doing this with external select. This is mainly out
> > of curiosity to know whether I really am going against the grain of
> > MHD's design here, or if instead I've  just overlooked something I
> > should/should not be doing. If this is something that should work,
> > then I can go into more detail about what I am doing/trying to do.
> 
> I'm not 100% sure of what you are doing, but the key rule is that
> MHD_queue_response has to be called from within the main handler callback.
> 
> I hope this helps!
> 
> Happy hacking!
> 
> Christian
> 

Generating a response requires forwarding another request off to 
a different web service, and then possibly waiting a while for that
service to respond to us, so we can respond to our client. I'm looking
at different ways to avoid tying up an MHD thread while waiting for
that response. External select is an obvious choice, but I was 
thinking I could get away with using internal select as well. Looks
like a "no". The work could be done on another thread and signaled
back to the MHD thread, but the latter would still be stuck waiting
for that signal, since it can't return from the access handler
until it has queued the response.

-Tom