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
by W. Richard Steve » Thu, 23 Jun 1994 05:07:26
The socket functions aren't in that table because the POSIX.12 socketQuote:> 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.
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
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.
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.
by Casper H.S. D » Thu, 23 Jun 1994 17:00:46
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
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.
If I recall the case with select() correctly, it tried to restart but its
timeout parameter had been trashed.
--
by Andrew Gra » Wed, 29 Jun 1994 06:33:40
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
7. --- called from signal handler with signal -24242176 (SIG Unknown)
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