Re: [libmicrohttpd] MHD_handle_connection race leads to deadlock in MHD_stop_daemon

[Mike Crowe]

On Tuesday 13 October 2009 17:41:12 Mike Crowe wrote:
>> I've found a difficult to reproduce deadlock in v0.4.2 when calling
>> MHD_stop_daemon while a connection is active. I narrowed it down to
>> MHD_handle_connection racing against MHD_cleanup_connections. It can
>> be reproduced much more easily by inserting a sleep just before the
>> call to SELECT in MHD_handle_connection. I'm using
>> MHD_USE_THREAD_PER_CONNECTION.

On Wed, Oct 14, 2009 at 02:44:58PM +0200, Christian Grothoff wrote:
> Yes, this looks like the usual race of select with a signal.  The pipe 
> approach is what I've usually taken in the past, but when MHD was written I 
> really wanted to avoid it (and I guess then the issue fell through the cracks 
> at some point).  
> 
> I've thought about the issue and I think the best solution is to do a bit of 
> busy-waiting: I've changed the code around SELECT to ensure that the maximum 
> timeout is 1s.  That way, if we miss the SIGALRM, we will still terminate 
> after at most 1s.  My feeling is that this is better than wasting 2 FDs on a 
> pipe.  Obviously I could be convinced of using a pipe instead if someone had 
> benchmarks that show that calling select every 1s is horrible.

I temporarily hacked around the problem by employing a similar
fix. It's not ideal, as you say, but it does work. I'm in favour of
it, at least in the short term.

I did wonder whether it would be possible to use pthread_cancel and
disable cancellation around calls to the callbacks but it would
require a bit of work to ensure that the necessary cleanup occurred.

It would appear that pselect is designed to solve this problem. I
might try using it if it is available and fall back to your fix if
not. Some care might be required if the code is relying on SIGALRM waking
up reads and writes as well as the select.

Thanks.

Mike.