List of routines safe to use in signals?

Heiko Blume src at scuzzy.in-berlin.de
Tue Dec 18 12:36:08 AEST 1990


jik at athena.mit.edu (Jonathan I. Kamens) writes:

>In article <1990Dec13.022804.7712 at scuzzy.in-berlin.de>, src at scuzzy.in-berlin.de (Heiko Blume) writes:
>|> don't get me wrong, but there are so many things that are in the
>|> man page, but just don't work.

>  Then they should be fixed as they are found.

sure, but what would you say if you can't mkfs a 512Byte Filesystem?
that's kind of weird for me, didn't anyone try that yet? (btw: i didn't
get any responses to my posting apart from 'why do you want to do that?').

>  A man page for a library function is a specification for that function. 
>Degenerating a little bit, a specification for a function is also a
>specification for that function.  The definition and purpose of a
>specification in computer programming is that it tells you, as a programmer,
>what YOU need to do and what the FUNCTION guarantees to do when you call it.

that's what i thought in the beginning. right now i have a real hard time
with the man pages for sig*(2). perhaps i should correct myself a bit:
it's not that there are many bugs in the man pages, it's what there
*isn't* in the man pages! for example what does sigsuspend(2) *really*
do? say, i block SIGCHLD. A child dies. The signal get's posted
to the parent. since it's blocked it's "pending". ok, what happens when
i call sigsuspend() then, with a mask all zeroes. the man page says it
suspends the process until the *delivery* of a signal not masked by
sigsuspend()'s argument. guess what, although the signal is pending,
the process gets blocked! WHY? [anyway, i'll elaborate on this in
another posting due soon...]

>  Saying that we shouldn't listen to what's in man pages because there are
>mistakes in man pages is like saying that whenever you put an answer into a
>crossword puzzle and peek at the answer key and it's different, you should
>assume that the answer key is wrong since there have been mistakes in answer
>keys in the past.

well, i didn't mean it that drastic, but i think there's at least a lot
missing in the man pages. especially something as complicated as the
(posix) signals should be documented minutely and with examples, or
at least not with sentences like:

"...when a signal is caught during a read(2), a write(2), an open(2),
or an ioctl(2) system call DURING a sigpause system call, or during a
wait(2) system call that does not return immediately due to the existance
of a previously stopped or zombie process, the signal-catching handler
will be executed."

during *WHAT* ??? (that's from sigset(2)). also, as far as i get it,
the BSD sigpause(2) is equivalent to posix sigsuspend(2), so what
has sigpause(2) to do in a posix environment anyway?


can someone give me a pointer to some documentation that *clearly*
explains posix signals and job control?!?!
-- 
      Heiko Blume <-+-> src at scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                    public source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home



More information about the Comp.unix.programmer mailing list