> > > Any program that counts on the behavior of signal() in this manner is
> > > broken. What part of that isn't clear?
> >
> > Nothing. It is clearly wrong.
>
> This is at variance with accepted practice. If you really need to
> choose whether you are going to get SA_ONESHOT or not, you use
> sigaction.
The problem is that people approach a particular system with
certain expectations based on past experience. It is not
unreasonable for glibc to have standardised on a single behaviour
since it is supposed to provide a consistent API on all systems.
One of the SYSV and BSD behaviours had to break (although I
personally would have done it the other way round).
The *real* problem is that, although the behaviour is documented
deep down in the glibc documentation, glibc comes without any
form of simple documentation that details the critical changes
on each system it builds for. The result is that a lot of people
are going to get confused, a lot of programs will have unexpected
problems.
(In fact the sqlexecd from Informix's Linux release seems to
have a related problem - it sets a SIGCHLD handler with signal()
and expects it to be sticky but it is linked against libc5. My
guess is that someone was working from documentation on a glibc
system but the final build was libc5 for maximum portability.)
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/