This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: ["E. Jay Berkenbilt" <ejb@apexinc.com>] libc/1298: malloc()/fork() deadlock with linuxthreads
- To: aj at suse dot de
- Subject: Re: ["E. Jay Berkenbilt" <ejb@apexinc.com>] libc/1298: malloc()/fork() deadlock with linuxthreads
- From: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- Date: 13 Nov 1999 16:11:56 -0000
- CC: libc-alpha at sourceware dot cygnus dot com, ejb at apexinc dot com
- References: <u8yac6pwn4.fsf@gromit.rhein-neckar.de>
> here's an unsolved bug report. Wolfram Gloger made the following
> comment (translated from German and abbreviated):
Thanks for the translation...
> Any comments?
This issue seem to stem from a more general and recognized problem in
the Posix standard.
========================================================================
David Butenhof writes in "Programming with Posix threads", 6.1, p. 198:
"So while it is legal to call fork from within a signal-catching
function, doing so may ... require performing other operations that
cannot be performed within a signal-catching function.
This is an inconsistency in the POSIX standard that will need to be
fixed. Nobody yet knows what the eventual solution will be. My
advice is to avoid using fork in a signal-catching function."
========================================================================
So I don't think we can (or should) do much now... I'd still like to
know if it is actually possible to decide whether the context of
execution is within a signal handler or not (in glibc only, of
course). It's probably impossible.
Regards,
Wolfram.