George Anzinger wrote:
> Kip Matthew Macy wrote:
> >
> > Read the man page again:
> >
> > <snip>
> >
> > ASYNC-SIGNAL SAFETY
> > The mutex functions are not async-signal safe. What this
> > means is that they should not be called from a signal han
> > dler. In particular, calling pthread_mutex_lock or
> > pthread_mutex_unlock from a signal handler may deadlock
> > the calling thread.
> >
> > </snip>
> <snip>
>
> Gosh, is this common or just a Linux'ism? Seems like a real drag and
> not to easy to get around.
>
> George
There is only a relatively small set of functions specified by posix as
being
async signal safe. From the FreeBSD sigaction man page:
<snip>
The following functions are either reentrant or not interruptible
by sig
nals and are async-signal safe. Therefore applications may invoke
them,
without restriction, from signal-catching functions:
Base Interfaces:
_exit(), access(), alarm(), cfgetispeed(), cfgetospeed(),
cfsetispeed(),
cfsetospeed(), chdir(), chmod(), chown(), close(), creat(), dup(),
dup2(), execle(), execve(), fcntl(), fork(), fpathconf(), fstat(),
fsync(), getegid(), geteuid(), getgid(), getgroups(), getpgrp(),
getpid(), getppid(), getuid(), kill(), link(), lseek(), mkdir(),
mkfifo(), open(), pathconf(), pause(), pipe(), raise(), read(),
rename(),
rmdir(), setgid(), setpgid(), setsid(), setuid(), sigaction(),
sigaddset(), sigdelset(), sigemptyset(), sigfillset(),
sigismember(),
signal(), sigpending(), sigprocmask(), sigsuspend(), sleep(),
stat(),
sysconf(), tcdrain(), tcflow(), tcflush(), tcgetattr(),
tcgetpgrp(),
tcsendbreak(), tcsetattr(), tcsetpgrp(), time(), times(), umask(),
uname(), unlink(), utime(), wait(), waitpid(), write().
Realtime Interfaces:
aio_error(), clock_gettime(), sigpause(), timer_getoverrun(),
aio_return(), fdatasync(), sigqueue(), timer_gettime(),
aio_suspend(),
sem_post(), sigset(), timer_settime().
All functions not in the above lists are considered to be unsafe
with re
spect to signals. That is to say, the behaviour of such functions
when
called from a signal handler is undefined.
</snip>
The last paragraph is noteworthy.
There are a lot of things one can get to work with threads on Solaris
that
technically should not. I once ported a piece of code from Solaris to
Linux
that had a shutdown bug that took me a long time to trackdown. It turned
out that the code was launching a thread from the signal handler. That
is
also not async-signal safe but works just fine under Solaris -under
linux
it caused an inconsistent set of behaviours.
So the short answer is, no, it is not a Linuxism. It is a shortcoming in
the
Posix spec. Sun just goes out of its way to make things like that work
anyway.
-Kip
-
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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:23 EST