Reentrant system calls (can be called from signal handler)

Reentrant system calls (can be called from signal handler)

Post by Russell Trott » Wed, 22 Jun 1994 23:55:04



Hello,

   There's a list of reentrant system calls in Richard Steven's book
"Advanced Programming in the UNIX environment" on pg. 278.  I was
wondering why/if there are any socket calls (socket, setsockopt, send, recv,
etc) in the list?  Thanks.

Russ

 
 
 

Reentrant system calls (can be called from signal handler)

Post by W. Richard Steve » Thu, 23 Jun 1994 05:07:26


Quote:>    There's a list of reentrant system calls in Richard Steven's book
> "Advanced Programming in the UNIX environment" on pg. 278.  I was
> wondering why/if there are any socket calls (socket, setsockopt, send, recv,
> etc) in the list?  Thanks.

The socket functions aren't in that table because the POSIX.12 socket
standardization isn't complete yet.  Looking at my draft of .12, I see
that they specify most of the socket functions as being reentrant.

Today, it'll depend on the implementation.  On a BSD system, where the
functions are system calls, they'll be reentrant.  But on a system
that implements sockets as a user library (e.g., SVR4), they may or
may not be, depending how the library was written.  Solaris 2.2 had
the problem where the sockets library wasn't thread-safe for this reason.

        Rich Stevens

 
 
 

Reentrant system calls (can be called from signal handler)

Post by David Jon » Thu, 23 Jun 1994 10:26:22



>Hello,

>   There's a list of reentrant system calls in Richard Steven's book
>"Advanced Programming in the UNIX environment" on pg. 278.  I was
>wondering why/if there are any socket calls (socket, setsockopt, send, recv,
>etc) in the list?  Thanks.

Aren't ALL system calls more or less re-entrant according to your definition?

Granted, using a system call to manipulate a resource from within a signal
handler, and outside the signal handler can lead to synchronization problems,
but, at least under NetBSD:

- A system call is either aborted or restarted due to a signal.

- Aborted system calls simply terminate, leaving no state that can be
  clobbered by the signal handler.

- System calls are restarted by backing up the program counter to point to
  the trap instruction that invoked the system call to begin with.  The
  system call then TERMINATES, and when the signal handler returns, the
  trap is re-executed, thereby restarting the system call.

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.

 
 
 

Reentrant system calls (can be called from signal handler)

Post by Casper H.S. D » Thu, 23 Jun 1994 17:00:46



>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.

Casper

 
 
 

Reentrant system calls (can be called from signal handler)

Post by Ted Stockwe » Fri, 24 Jun 1994 03:59:50




>   >Hello,

>   >   There's a list of reentrant system calls in Richard Steven's book
>   >"Advanced Programming in the UNIX environment" on pg. 278.  I was
>   >wondering why/if there are any socket calls (socket, setsockopt, send, recv,
>   >etc) in the list?  Thanks.

>   Aren't ALL system calls more or less re-entrant according to your definition?

>   Granted, using a system call to manipulate a resource from within a signal
>   handler, and outside the signal handler can lead to synchronization problems,
>   but, at least under NetBSD:

>   - A system call is either aborted or restarted due to a signal.

>   - Aborted system calls simply terminate, leaving no state that can be
>     clobbered by the signal handler.

>   - System calls are restarted by backing up the program counter to point to
>     the trap instruction that invoked the system call to begin with.  The
>     system call then TERMINATES, and when the signal handler returns, the
>     trap is re-executed, thereby restarting the system call.

What is true of NetBSD can't be assumed to be true of anything else.  If
it is not on Stevens' Sacred list of page 278, you can't trust the system
call to be signal reentrant -- at least not if you want to write portable
code.  I've seen interesting behaviours with gettimeofday() and select().

If I recall the case with select() correctly, it tried to restart but its
timeout parameter had been trashed.
--

 
 
 

Reentrant system calls (can be called from signal handler)

Post by Andrew Gra » Wed, 29 Jun 1994 06:33:40




|>
|> >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.    

--
Andrew D.Grant

 
 
 

1. Calling non-reentrant functions in signal handlers

NCSA httpd 1.4.2 contains several function calls in its SIGPIPE
and SIGALRM handler that are definitely not reentrant -- free(),
for example.  A quick look at Apache shows that they have
wisely pulled all this code out of the signal handler.

Is there some thing I'm missing about NCSA's setup that makes
this safe? Are people getting sporadic unexplained coredumps
when running NCSA, especially under weird network conditions that
might generate a lot of broken connections? Any Apache and/or
NCSA developers out there that might want to comment?

Another question: why is SIGPIPE being handled this way at all?
Why aren't the return values from write calls being checked to verify
the pipe hasn't broken?

 -PSP

--
"perl -e goto produces an exception under DOS and a 'Segmentation fault'
 under Linux." -- Tony Cook, comp.lang.perl
"Sorry, this feature was not preserved in Perl 5."  
    -- Larry Wall, comp.lang.perl

2. setsid and streams/device driver output to controlling terminal

3. Threads performance - allow signal handler to not call handler

4. /etc/aliases

5. System calls inside signal handlers

6. inserting texts in a file

7. --- called from signal handler with signal -24242176 (SIG Unknown)

8. Linux X not stable

9. signals, signal handlers, glibc reentrant?

10. How I could add a new system call to linux or modify a system calls

11. How to use open system call in a new system call

12. "Interrupted system call" at "low level" - system calls

13. Address of function calling signal handler