[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    [PATCH] libc: make system() block SIGCHLD
From:       vapier () gentoo ! org (Mike Frysinger)
Date:       2012-01-16 10:16:17
Message-ID: 201201160516.18433.vapier () gentoo ! org
[Download RAW message or body]

On Monday 16 January 2012 04:00:08 Richard Braun wrote:
> On Sun, Jan 15, 2012 at 06:51:15PM -0500, Mike Frysinger wrote:
> > On Sunday 15 January 2012 14:36:55 Richard Braun wrote:
> > > On Sun, Jan 15, 2012 at 10:04:58AM -0500, Rich Felker wrote:
> > > > Your report is wrong. system is REQUIRED by POSIX to change the
> > > > signal disposition for SIGCHLD, not just to block the signal. It
> > > > should change it to SIG_IGN, not SIG_DFL, but for practical purposes
> > > > these are the same or similar.
> > > 
> > > I didn't notice that anywhere. Could you indicate where this behaviour
> > > is specified exactly ?
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html
> > 
> > 	The system() function shall ignore the SIGINT and SIGQUIT signals, and
> > 	shall block the SIGCHLD signal, while waiting for the command to
> > 	terminate
> 
> That part doesn't state "system is REQUIRED by POSIX to change the
> signal disposition for SIGCHLD, not just to block the signal", on the
> contrary, which is why I'm asking.

you're right ... i don't see POSIX requiring the signal disposition being 
reset.  Rich will have to explain why he thinks it does.  the POSIX example at 
the end of the system() page doesn't do that either.

> > > I agree the use of signal() immediately disturbed me, but I didn't read
> > > its implementation. Maybe it does the job. In any case, we could use
> > > the occasion to fix that as well and replace signal() with sigaction()
> > > in the same patch.
> > 
> > Rich is referring to the extended aspects of signal handling that
> > sigaction() enables over signal() such as sa_sigaction and sa_flags. 
> > signal() will save/restore the handler just fine, but otherwise this
> > function does subtly break a few things ...
> 
> Sure, but I was implying the implementation of signal() might have used
> some trick to correctly handle such cases, which is highly unlikely.

the only trick signal() itself does is change its default behavior based on 
the feature macros in use.  see the end of the signal(2) man page (portability 
section) where it describes the behavior under Linux.

there's no sane way for it to save/restore the full signal handling state 
since the return value is a single pointer.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120116/8d6a15c2/attachment.asc>

[prev in list] [next in list] [prev in thread] [next in thread]