On Mon, Oct 24, 2016 at 11:16:05PM +0200, Christian Grothoff wrote: > On 10/24/2016 10:13 PM, Tom Cornell wrote: > > > > 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. > > The latter is incorrect. You can totally return from the access handler > without queueing a response. Simply return "MHD_YES". MHD will call you > again "immediately" in this case (next iteration of event loop). To > avoid busy waiting, suspend the connection. Then resume it whenever you > have the response ready, wait to be called again, then give MHD the > now-ready response.
Hmmm. Okay. I was already returning from the access handler without queuing a response (since that was happening on another thread), but I am not seeing this subsequent extra call to the access handler. Is that because I am suspending the connection before returning? (I also don't see it after resuming the connection, but since at that point I've queued a response in a different thread, presumably I'm well into the world of Undefined Behavior at that point.) I will rework the code along the lines you suggest. Thanks for the quick reply!
