Is clock_nanosleep() async-signal safe? - Unix

This is a discussion on Is clock_nanosleep() async-signal safe? - Unix ; 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: ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Is clock_nanosleep() async-signal safe?

  1. 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/...ons/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.

  2. Re: Is clock_nanosleep() async-signal safe?

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

  3. Re: Is clock_nanosleep() async-signal safe?

    Geoff Clare wrote:

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


    Can you explain how the "Open Group Base Specifications Issue 6" relates
    to SUSv2 and SUSv3?

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


    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/cv...&cvsroot=glibc

    >> In general, is it legal to sleep in a signal handler?

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

  4. Re: Is clock_nanosleep() async-signal safe?

    Spoon wrote:

    >>> The Open Group Base Specifications Issue 6 states:

    [...]
    >> 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?


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

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

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

    >>> In general, is it legal to sleep in a signal handler?

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


    Yes, it seems that way.

    --
    Geoff Clare

+ Reply to Thread