Re: [libmicrohttpd] Race condition when enqueing

[Christian Grothoff]

Dear Mike,

Testcase looks good, and yes, there was a second small issue with my small 
preliminary patch: your handler should not have been called again after 
queuing the response.  I've fixed that in the final patch (just committed -- 
with your testcase) as revision 10530 to SVN HEAD.

Thanks for reporting & helping with the fix!

Happy hacking

Christian

On Wednesday 10 March 2010 01:03:42 pm Mike Crowe wrote:
> On Wed, Mar 10, 2010 at 11:27:46AM +0000, Mike Crowe wrote:
> > I've done some more digging and it would appear that the default
> > handler is called again after the response has been queued. The test
> > case didn't differentiate between the first call and subsequent calls
> > so MHD_queue_response was called again in error.
> >
> > If I arrange for the handler to be happy being called twice then your
> > patch appears to solve the problem.
> 
> I've attached an updated test case patch. It tests all combinations of
> expect continue, chunked, slow body and form data. Unfortunately it
> doesn't report unique error results for all of them. Note that it
> specifically tests the case of queuing a response without expecting
> continue that you said isn't supported. It does seem to work in my
> testing though. :)
> 
> If you happen to know the correct incantation to tell Emacs to format
> the code the way you like it then it would make it easier for me to
> turn the test case into something you can merge.
> 
> > This second call is coming from the MHD_CONNECTION_FOOTERS_RECEIVED
> > case. I'm not sure whether it is to be expected or not. My real code
> > doesn't cope with being called twice in this situation either though
> > so I'll need to do some work there too.
> >
> > (The problem I'm trying to solve here is dealing with C++ handlers
> > that throw exceptions. I need to catch the exception and report a 500
> > error. These exceptions could be generated by the very code that sets
> > up the state which the handler uses to differentiate the subsequent
> > calls to the handler.)
> 
> It turns out that my real code did know that the handler had been
> called a second time. It just happened to fall through all its
> possible actions and ended up returning MHD_NO. Changing this to
> MHD_YES made everything work again.
> 
> Thanks again for all your help.
> 
> Mike.
>