|
Home > Archive > Unix Programming > November 2007 > Is clock_nanosleep() async-signal safe?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is clock_nanosleep() async-signal safe?
|
|
|
| Hello,
The Open Group Base Specifications Issue 6 states:
3.26 Async-Signal-Safe Function
A function that may be invoked, without restriction, from
signal-catching functions. No function is async-signal-safe unless
explicitly described as such.
The older Single UNIX Specification, Version 2 stated:
* When signal-catching functions are invoked asynchronously
with process execution, the behaviour of some of the functions defined
by this document is unspecified if they are called from a
signal-catching function.
The following table defines a set of interfaces that are
either reentrant or not interruptible by signals 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 table are considered to be unsafe with
respect to signals. In the presence of signals, all functions defined by
this specification will behave as defined when called from or
interrupted by a signal-catching function, with a single exception: when
a signal interrupts an unsafe function and the signal-catching function
calls an unsafe function, the behaviour is undefined.
sleep() used to be considered Async-Signal-Safe.
Is this not true anymore?
http://www.opengroup.org/onlinepubs...ions/sleep.html
(sleep is not explicitly described as Async-Signal-Safe.)
Is clock_nanosleep() also not Async-Signal-Safe?
http://www.opengroup.org/onlinepubs..._nanosleep.html
In general, is it legal to sleep in a signal handler?
Regards.
| |
| Geoff Clare 2007-11-27, 1:30 pm |
| Spoon wrote:
> The Open Group Base Specifications Issue 6 states:
>
> 3.26 Async-Signal-Safe Function
>
> A function that may be invoked, without restriction, from
> signal-catching functions. No function is async-signal-safe unless
> explicitly described as such.
>
> The older Single UNIX Specification, Version 2 stated:
>
> * When signal-catching functions are invoked asynchronously
> with process execution, the behaviour of some of the functions defined
> by this document is unspecified if they are called from a
> signal-catching function.
>
> The following table defines a set of interfaces that are
> either reentrant or not interruptible by signals and are async-signal
> safe. Therefore applications may invoke them, without restriction, from
> signal-catching functions:
>
[...]
> sigismember() signal() sigpending() sigprocmask() sigsuspend() sleep()
[...]
>
> All functions not in the above table are considered to be unsafe with
> respect to signals.
> sleep() used to be considered Async-Signal-Safe.
> Is this not true anymore?
> http://www.opengroup.org/onlinepubs...ions/sleep.html
> (sleep is not explicitly described as Async-Signal-Safe.)
sleep() is still async-signal-safe. SUSv3 has much the same text, and
list of functions, that you quoted from SUSv2. See the end of XSH6
section 2.4.3.
> Is clock_nanosleep() also not Async-Signal-Safe?
> http://www.opengroup.org/onlinepubs..._nanosleep.html
clock_nanosleep() is not in the list in XSH6 2.4.3, so it is not
async-signal-safe (neither is nanosleep()).
> In general, is it legal to sleep in a signal handler?
Only using sleep().
--
Geoff Clare <netnews@gclare.org.uk>
| |
|
| Geoff Clare wrote:
> Spoon wrote:
>
> [...]
> [...]
>
>
> sleep() is still async-signal-safe. SUSv3 has much the same text, and
> list of functions, that you quoted from SUSv2. See the end of XSH6
> section 2.4.3.
Can you explain how the "Open Group Base Specifications Issue 6" relates
to SUSv2 and SUSv3?
>
> clock_nanosleep() is not in the list in XSH6 2.4.3, so it is not
> async-signal-safe (neither is nanosleep()).
I had always assumed that sleep() was a fancy wrapper around
nanosleep(). (Which is the case in the Linux glibc implementation.)
http://sources.redhat.com/cgi-bin/c...7&cvsroot=glibc
>
> Only using sleep().
That's odd. How does one sleep less than a second in a signal handler?
It seems one has to resort to the select hack?
Regards.
| |
| Geoff Clare 2007-11-28, 1:25 pm |
| Spoon wrote:
[...][vbcol=seagreen]
>
> Can you explain how the "Open Group Base Specifications Issue 6" relates
> to SUSv2 and SUSv3?
Issue 6 is SUSv3, Issue 5 was SUSv2 (and Issue 4 Version 2 was SUSv1,
and Issue 4 was XPG4 which was the last time the numbers matched).
>
> I had always assumed that sleep() was a fancy wrapper around
> nanosleep(). (Which is the case in the Linux glibc implementation.)
sleep() predates nanosleep() by many years, so I think on most
implementations they are implemented separately. Historically
sleep() was implemented using alarm().
>
> That's odd. How does one sleep less than a second in a signal handler?
> It seems one has to resort to the select hack?
Yes, it seems that way.
--
Geoff Clare <netnews@gclare.org.uk>
|
|
|
|
|