libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Grothoff
Subject: Re: [libmicrohttpd] MHD_handle_connection race leads to deadlock in MHD_stop_daemon
Date: Thu, 15 Oct 2009 14:37:27 +0200
User-agent: KMail/1.12.2 (Linux/2.6.28-grml64; KDE/4.3.2; x86_64; ; )

On Thursday 15 October 2009 10:35:01 Mike Crowe wrote:
> On Wednesday 14 October 2009 15:13:02 Mike Crowe wrote:
> >> 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.
> 
> On Thu, Oct 15, 2009 at 09:34:21AM +0200, Christian Grothoff wrote:
> > pselect was designed to solve the problem, but pselect is not as portable
> > *and* on some systems (glibc!) the specific implementation of pselect
> > still has the same problem (see select man page).  So I don't think
> > pselect is a worthwile direction to go into.
> 
> Despite what the man page says my glibc appears to have a correct
> pselect implementation for Linux (in sysdeps/unix/sysv/linux/pselect.c
> - probably added in early 2006.) It would appear that support for the
> syscall was added in the v2.6.16 kernel[1]. Quite how this correct
> support can be distinguished at runtime or compile time though I'm not
> sure.

That's exactly the critical question here: how can we be *certain* that the 
pselect call will work? If there is a good auto-conf-ish answer to that, I 
would not mind adding an #ifdef where appropriate.  Clearly testing that a 
data-race is guaranteed not to happen is a bit tricky, even if we don't even 
consider cross-compilation.

Best,

Christian
-- 
http://grothoff.org/christian/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]