Austin Group Bug Tracker
2014-08-05 22:09:46 UTC
The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=863
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 863
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: pthread_once
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-05 22:09 UTC
Last Modified: 2014-08-05 22:09 UTC
======================================================================
Summary: Explicitly disallow longjmp from pthread_once
init_routine
Description:
As written, the specification for pthread_once assumes that init_routine
either returns or acts on thread cancellation. However, there is a third
possibility which is unaddressed: that execution of init_routine ends with
a call to longjmp.
Based on a strict reading of the specification, I think the requirement
here is that all subsequent calls to pthread_once (with the same
once_control) deadlock if the init_routine ended with longjmp. This is
because:
A. "Subsequent calls of pthread_once() with the same once_control shall not
call the init_routine." and this requirement is only relaxed when
init_routine is cancelled: "if init_routine is a cancellation point and is
canceled, the effect on once_control shall be as if pthread_once() was
never called." Thus subsequent calls after the first ended by longjmp
cannot call the init_routine again.
B. "On return from pthread_once(), init_routine shall have completed."
Thus, subsequent calls after the first ended by longjmp cannot return,
since init_routine has not completed.
However, I don't think this behavior is useful, and allowing longjmp at all
it makes it difficult to implement pthread_once, since the natural way of
handling cancellation uses pthread_cleanup_push, while longjmp out of a
pthread_cleanup_push context is not permitted.
Note that allowing longjmp and having pthread_once behave the same way when
init_routine ends with longjmp as it does when init_routine is cancelled
does not seem like a viable option. In order for this to work, longjmp must
be implemented via some sort of unwinding that can reset the state of the
once_control object. I do not think forbidding all traditional
implementations of setjmp/longjmp as mere register save/restore is the
intent of this standard or within the scope of fixing this issue in
pthread_once.
Desired Action:
Add to the description of pthread_once:
"If init_routine calls longjmp[OB XSI][Option Start], _longjmp,[Option End]
or siglongjmp, the behavior is undefined."
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2014-08-05 22:09 dalias New Issue
2014-08-05 22:09 dalias Name => Rich Felker
2014-08-05 22:09 dalias Organization => musl libc
2014-08-05 22:09 dalias Section => pthread_once
2014-08-05 22:09 dalias Page Number => unknown
2014-08-05 22:09 dalias Line Number => unknown
======================================================================
======================================================================
http://austingroupbugs.net/view.php?id=863
======================================================================
Reported By: dalias
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 863
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Rich Felker
Organization: musl libc
User Reference:
Section: pthread_once
Page Number: unknown
Line Number: unknown
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-05 22:09 UTC
Last Modified: 2014-08-05 22:09 UTC
======================================================================
Summary: Explicitly disallow longjmp from pthread_once
init_routine
Description:
As written, the specification for pthread_once assumes that init_routine
either returns or acts on thread cancellation. However, there is a third
possibility which is unaddressed: that execution of init_routine ends with
a call to longjmp.
Based on a strict reading of the specification, I think the requirement
here is that all subsequent calls to pthread_once (with the same
once_control) deadlock if the init_routine ended with longjmp. This is
because:
A. "Subsequent calls of pthread_once() with the same once_control shall not
call the init_routine." and this requirement is only relaxed when
init_routine is cancelled: "if init_routine is a cancellation point and is
canceled, the effect on once_control shall be as if pthread_once() was
never called." Thus subsequent calls after the first ended by longjmp
cannot call the init_routine again.
B. "On return from pthread_once(), init_routine shall have completed."
Thus, subsequent calls after the first ended by longjmp cannot return,
since init_routine has not completed.
However, I don't think this behavior is useful, and allowing longjmp at all
it makes it difficult to implement pthread_once, since the natural way of
handling cancellation uses pthread_cleanup_push, while longjmp out of a
pthread_cleanup_push context is not permitted.
Note that allowing longjmp and having pthread_once behave the same way when
init_routine ends with longjmp as it does when init_routine is cancelled
does not seem like a viable option. In order for this to work, longjmp must
be implemented via some sort of unwinding that can reset the state of the
once_control object. I do not think forbidding all traditional
implementations of setjmp/longjmp as mere register save/restore is the
intent of this standard or within the scope of fixing this issue in
pthread_once.
Desired Action:
Add to the description of pthread_once:
"If init_routine calls longjmp[OB XSI][Option Start], _longjmp,[Option End]
or siglongjmp, the behavior is undefined."
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2014-08-05 22:09 dalias New Issue
2014-08-05 22:09 dalias Name => Rich Felker
2014-08-05 22:09 dalias Organization => musl libc
2014-08-05 22:09 dalias Section => pthread_once
2014-08-05 22:09 dalias Page Number => unknown
2014-08-05 22:09 dalias Line Number => unknown
======================================================================