|Anonymous | Login||2023-06-04 20:13 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000625||[1003.1(2008)/Issue 7] System Interfaces||Objection||Clarification Requested||2012-10-22 05:32||2019-06-10 08:55|
|Priority||normal||Resolution||Accepted As Marked|
|Section||sleep, XSH 2.9.1|
|Final Accepted Text||Note: 0001430|
|Summary||0000625: Allowing alarm-based sleep() implementation contradicts requirement of thread-safety|
The description and rationale for the sleep function are full of legacy allowances for the possibility that sleep is implemented in terms of alarm/SIGALRM. Such an implementation is fundamentally not thread-safe, but sleep is not listed in the set of non-thread-safe functions in XSH 2.9.1 nor is it documented as non-thread-safe in its description.
Note that the legacy alarm-based implementations are not only non-thread-safe; they cannot even work at all in a multi-threaded program. The approach of using a signal handler and longjmp does not work because it is impossible to control which thread the signal handler runs in. The approach of blocking the signal and using sigsuspend does not work because the signal may be acted upon (by default, resulting in program termination) in any other thread that has the signal unblocked. It may be possible to design a new alarm-based implementation that works around these issues, but as nanosleep is a mandatory interface, trying to design a new alarm-based implementation seems counter-productive.
Either add sleep to the list of non-thread-safe functions, or remove all language suggesting that sleep could be implemented in terms of alarm.
Implementations can have two versions of sleep(): one in libc that uses
SIGALRM and one in libpthread that does not.
Instead of removing the text relating to SIGALRM, it should be made
conditional on the program not having been linked with -l pthread.
For example, a new second paragraph could be added to the DESCRIPTION
saying something like:
In programs linked without -l pthread (see [xref to XCU c99]), sleep()
may make use of SIGALRM. In programs linked with -l pthread, sleep()
shall not make use of SIGALRM and the remainder of this DESCRIPTION
does not apply.
To my knowledge, the language "linked with[out]" is not used elsewhere in the standard. Also, the semantics of the c99 utility seem to apply only to implementations that support the [CD] option, so it is less than optimal for the semantics of sleep() to be specified in terms of behavior of the c99 utility.
Rather than making the behavior conditional on "linking", why not use something along the lines of the following:
"In any program which has or may come to have multiple threads, the remainder of this DESCRIPTION shall not apply; in particular, sleep() shall not alter any signal dispositions."
This also allows implementations that choose a version of sleep based on runtime characteristics, or weak symbols, or some other mechanism different from -l options when linking.
This was discussed in the 5th December teleconference and some
additional issues were noted:
If an application is not linked with -l pthread but the implementation
might create additional threads "under the covers" of its own accord,
then the implementation should not use SIGALRM in sleep().
If an application is not linked with -l pthread but later uses
dlopen() to load either libpthread or a library that has libpthread as
a dependency, and then creates an additional thread, this could result
in the SIGALRM-based sleep() being used while the process is
multithreaded. This is a more general problem that affects more
things than sleep(), and the standard should say the behaviour is
undefined if an application does this.
The consensus was that we should eliminate all of the problems
associated with SIGALRM-based sleep by disallowing it in Issue 8, and
a Future Directions note should be added in TC2 to warn about this.
However, something still needs to be done in TC2 to resolve the
problem with Issue 7 without requiring implementations to change.
edited on: 2012-12-20 16:59
The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
The standard does not adequately address the differences
between single-threaded and multi-threaded processes and
Notes to the Editor (not part of this interpretation):
Add a new paragraph after page 1963 line 62339:
In single-threaded programs, sleep() may make use of SIGALRM. In
multi-threaded programs, sleep() shall not make use of SIGALRM and
the remainder of this DESCRIPTION does not apply.
On page 1963 line 62369 in the RATIONALE change:
This volume of POSIX.1-2008 permits either approach.
This volume of POSIX.1-2008 permits either approach in
single-threaded programs, but the simple alarm/suspend
implementation is not appropriate for multi-threaded programs.
On page 1964 line 62406 change the FUTURE DIRECTIONS section from:
A future version of this standard may require that sleep() does
not make use of SIGALRM in all programs, not just multi-threaded
Cross-volume changes to XBD...
Add the following definitions in XBD chapter 3, in alphabetical order:
A library containing object files that were produced by compiling with c99
using the flags output by getconf POSIX_V7_THREADS_CFLAGS, or by
compiling using a non-standard utility with equivalent flags, and
which makes use of interfaces that are only made available by c99 when
the -l pthread option is used or makes use of SIGEV_THREAD notifications.
A process that contains more than one thread.
A program whose executable file was produced by compiling with c99
using the flags output by getconf POSIX_V7_THREADS_CFLAGS, and linking
with c99 using the flags output by getconf POSIX_V7_THREADS_LDFLAGS
and the -l pthread option, or by compiling and linking using a
non-standard utility with equivalent flags. Execution of a
multi-threaded program initially creates a single-threaded process;
the process can create additional threads using pthread_create() or
A process that contains a single thread.
A program whose executable file was produced by compiling with c99
without using the flags output by getconf POSIX_V7_THREADS_CFLAGS and
linking with c99 using neither the flags output by getconf
POSIX_V7_THREADS_LDFLAGS nor the -l pthread option, or by compiling
and linking using a non-standard utility with equivalent flags.
Execution of a single-threaded program creates a single-threaded
process; if the process attempts to create additional threads using
pthread_create() or SIGEV_THREAD notifications, the behavior is
undefined. If the process uses dlopen() to load a multi-threaded
library, the behavior is undefined.
|Interpretation Proposed 29 Mar 2013|
|Interpretation approved 3 May 2013|
|2012-10-22 05:32||dalias||New Issue|
|2012-10-22 05:32||dalias||Status||New => Under Review|
|2012-10-22 05:32||dalias||Assigned To||=> ajosey|
|2012-10-22 05:32||dalias||Name||=> Rich Felker|
|2012-10-22 05:32||dalias||Organization||=> musl libc|
|2012-10-22 05:32||dalias||Section||=> sleep, XSH 2.9.1|
|2012-10-22 05:32||dalias||Page Number||=> unknown|
|2012-10-22 05:32||dalias||Line Number||=> unknown|
|2012-10-22 08:03||geoffclare||Note Added: 0001406|
|2012-10-22 13:03||dalias||Note Added: 0001407|
|2012-12-05 17:41||geoffclare||Note Added: 0001428|
|2012-12-12 17:38||geoffclare||Note Added: 0001430|
|2012-12-20 16:43||geoffclare||Note Edited: 0001430|
|2012-12-20 16:48||geoffclare||Note Edited: 0001430|
|2012-12-20 16:59||geoffclare||Note Edited: 0001430|
|2012-12-20 17:00||geoffclare||Interp Status||=> Pending|
|2012-12-20 17:00||geoffclare||Final Accepted Text||=> Note: 0001430|
|2012-12-20 17:00||geoffclare||Status||Under Review => Interpretation Required|
|2012-12-20 17:00||geoffclare||Resolution||Open => Accepted As Marked|
|2012-12-20 17:00||geoffclare||Tag Attached: tc2-2008|
|2013-03-29 08:05||ajosey||Interp Status||Pending => Proposed|
|2013-03-29 08:05||ajosey||Note Added: 0001520|
|2013-05-03 12:19||ajosey||Interp Status||Proposed => Approved|
|2013-05-03 12:19||ajosey||Note Added: 0001575|
|2019-06-10 08:55||agadmin||Status||Interpretation Required => Closed|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|