[Top][All Lists]
[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/