View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000625 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2012-10-22 05:32 | 2019-06-10 08:55 |
| Reporter | dalias | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Rich Felker | ||||
| Organization | musl libc | ||||
| User Reference | |||||
| Section | sleep, XSH 2.9.1 | ||||
| Page Number | unknown | ||||
| Line Number | unknown | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000625:0001430 | ||||
| Summary | 0000625: Allowing alarm-based sleep() implementation contradicts requirement of thread-safety | ||||
| Description | 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. | ||||
| Desired Action | 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. | ||||
| Tags | tc2-2008 | ||||
|
|
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. |
|
|
Interpretation response ------------------------ 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. Rationale: ------------- The standard does not adequately address the differences between single-threaded and multi-threaded processes and programs. 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. to 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: None. to: A future version of this standard may require that sleep() does not make use of SIGALRM in all programs, not just multi-threaded programs. Cross-volume changes to XBD... Add the following definitions in XBD chapter 3, in alphabetical order: Multi-threaded library 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. Multi-threaded process A process that contains more than one thread. Multi-threaded program 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 SIGEV_THREAD notifications. Single-threaded process A process that contains a single thread. Single-threaded program 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 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 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 | => 0000625: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 |
