|> >Based on these observations, the kernel maintains no state that can be
|> >fatally overwritten by doing something * from within a signal handler.
|> >However, there are resource interactions that can cause problems. In
|> >particular, things like strtok(), malloc(), stdio are NOT reentrant,
|> >and should not be used inside a signal handler. But systems calls are
|> >not like this - if a particular call sequence is fatal to your program,
|> >then it is due to improper resource utilization planning on your part.
|> Well, that is also dependent on the implementation. E.g., Solaris 2.3
|> has reentrant stdio calls. (What they call ``Async-Safe'').
|> This requires blocking signals in critical sections, no doubt,
|> but if you have made them MT-Safe (thread safe) then there's
|> no problem locating the critical sections and blocking signals there.
I assume that by stdio you are talking about those functions which return
a file pointer rather than a file handle. These are not system calls, neither
is strtok() or malloc().
Since system calls can not be pre-empted, they do not need to be re-entrant
to be thread safe. The only exceptions are system calls which cause a process
to sleep. It is important to be aware that in SVR4, on which Solaris is based,
the socket calls are not implemented as system calls.