On Wed, Sep 26, 2001 at 18:19:38 +0500, Alexander Barkov wrote:
>
> Are you sure that those functions are not thread-safe?
I say nothing about thread-safeness, I mean they are not SIGNAL-safe (f.e.
all stdio including exit() (but not _exit()) is not signal-safe).
> I didn't know about that. Have you any related
> documentation? Man pages don't provide any information
> about it.
Quote from sigacton(2), FreeBSD-current:
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().
ANSI C Interfaces:
strcpy(), strcat(), strncpy(), strncat(), and perhaps some others.
Extension Interfaces:
strlcpy(), strlcat().
All functions not in the above lists are considered to be unsafe with
respect to signals. That is to say, the behaviour of such functions when
called from a signal handler is undefined. In general though, signal
handlers should do little more than set a flag; most other actions are
not safe.
Also, it is good practice to make a copy of the global variable errno and
restore it before returning from the signal handler. This protects
against the side effect of errno being set by functions called from
inside the signal handler.
--
Andrey A. Chernov
http://ache.pp.ru/
___________________________________________
If you want to unsubscribe send "unsubscribe general"
to [EMAIL PROTECTED]
