Re: [libmicrohttpd] Trouble getting a response sent from a separate worker thread (with external select)

[Christian Grothoff]

On 11/04/2014 08:11 PM, Tom Cornell wrote:
>> Date: Tue, 04 Nov 2014 18:44:53 +0100
>> From: Christian Grothoff <address@hidden>
>> To: address@hidden
>> Subject: Re: [libmicrohttpd] Trouble getting a response sent from a
>>      separate worker thread (with external select)
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Dear Tom,
>>
>> Did you pass the "MHD_USE_SUSPEND_RESUME" flag? Also, you're not
>> supposed to call 'MHD_queue_response" from anywhere but the access
>> handler callback, so if you call it from another thread, the behavior is not
>> defined (or, more likely, you got an error value returned and thus your
>> response was NOT actually queued but refused --- did you check the return
>> value?).
>>
>> So please (1) check return values, (2) pass USE_SUSPEND_RESUME, and
>> (3) call 'resume' from the other thread but queue the reply in the access
>> handler.  After that, it should work. If it does not, make sure you run a 
>> recent
>> MHD release. If that still fails, a testcase to reproduce would likely be
>> helpful...
>>
>> Happy hacking!
>>
>> Christian
> 
> First off, thanks for the quick reply!
> 
> (1) Yes -- In particular, the call to MHD_queue_response returned MHD_YES.
>  (And the response did eventually get sent, only select() had to time out 
> first. 
> Then control returned to the main loop and the next call to select() 
> picked up the response and sent it.)

Ah, yes, I overlooked that detail in your message.

> (2) I did set the USE_SUSPEND_RESUME flag on starting the daemon. 
> (Learned that lesson early on.)

:-).

> (3) I guess this must be the problem then. 
> So I can create the MHD_Response and queue it in the access handler, 
> but fill in the response data (status code, body) elsewhere, at a later time? 
> Do I need to be using MHD_create_response_from_callback to create 
> the MHD_Response? Or does that not matter?

You cannot set the status code after queuing.  But the *idea* is that
you call resume, and then the access handler *should* be called
"immediately" allowing you to queue the response with the status code.

> This is version 0.9.37, built from source on CentOS 6, just for completeness.

Ah, CentOS.  That platform is obviously less tested as I have no access.
So if, after doing (3), you still have the issue, producing a testcase
would be particularly helpful as I could check if the same issue is
present on other platforms or if it is CentOS-specific.

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature