Austin Group Defect Tracker

Aardvark Mark IV

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
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
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 Note: 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
Attached Files

- Relationships

-  Notes
(0001406)
geoffclare (manager)
2012-10-22 08:03

 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.
(0001407)
dalias (reporter)
2012-10-22 13:03

 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.
(0001428)
geoffclare (manager)
2012-12-05 17:41

 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.
(0001430)
geoffclare (manager)
2012-12-12 17:38
edited on: 2012-12-20 16:59

 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.
(0001520)
ajosey (manager)
2013-03-29 08:05

 Interpretation Proposed 29 Mar 2013
(0001575)
ajosey (manager)
2013-05-03 12:19

 Interpretation approved 3 May 2013

- Issue History
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 => 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
Powered by Mantis Bugtracker