| |
Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • ShopThe Open Brand -- Problem Reporting and Interpretations System |
|
Problem Report 2031 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 2031.
Report 2031 Actions
Problem Report Number 2031 Submitter's Classification Test Suite problem State Resolved Resolution Temporary Interpretation (TIN) Problem Resolution ID TIN.X.0092 Raised 1970-01-01 08:00 Updated 2003-03-13 08:00 Published 1998-05-12 08:00 Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98) Certification Program The Open Brand certification program Test Suite VSTH version 5.1.2 Test Identification PTHR.os/all/pthread_exit 3 Specification System Interfaces and Headers Issue 5 Location in Spec See Problem Text Problem Summary TIN5TH.00003 POSIX 1003.1 1996, page 347 section 18.1 Thread Cancellation Overview, provides a concise summary of the thread functionality. On lines 15-19 it states ... Applications also need to follow carefully s... Problem Text
POSIX 1003.1 1996, page 347 section 18.1 Thread Cancellation Overview,
provides a concise summary of the thread functionality.
On lines 15-19 it states
... Applications also need to follow carefully static lexical scoping
rules in their execution behavior. For instance, use of setjmp(), return,
goto, etc, to leave user-defined cancellation scopes without doing
the necessary scope pop operation will result in undefined behavior.
On page 352, section 18.2.3.2 which defines the scope and behavior of
pthread_cleanup_push() and pthread_cleanup_pop() says that since these
functions may be implemented as macros they must be within the same lexical
scope. The informative section B.18.2.3 Establishing Cancellation Handlers,
restates in detail that implementations can provide their macro definitions for
this functionality and must exist within the same scope as it is tied within
the same block of execution. Both sections specifically list the longjmp() as
an issue of leaving the scope of the thread and that such behavior is
undefined unless the implemenation decides to provide additional support of
calling the cancellation handlers. Not required but a suggestion.
The overview section specifically defines goto, return and etc. This is
a statement that a program being executed has many ways to leave the scope
of the thread and not executing a pop operation results in undefined behavior.
The test code in question has the following structure
void handler ()
{
printf("cleanup handler0);
}
static int tcount;
void* worker_thread (void* arg)
{
pthread_cleanup_push(handler, 0);
printf("thread exiting, cleanup should be called0);
return;
pthread_cleanup_pop(0);
}
The implementation under test is in line with the section 18.1
Thread Cancellation Overview, allocation of cleanup handlers
is done within a scope. The execution of the return statement
will be exiting the scope of the thread and undefined behavior
will result. The overview is providing the message that application
using threads must explicitly push and pop cancellation handlers to
be assured of thread behavior.
The requestor believes the overview section clearly states the intent
that the return function places the application outside of the thread scope.
The test code is broken by leaving the scope of the thread, executing the
return, and once outside the scope assumes that cancellation handlers
which are on a thread stack are available and have been executed. There
is no explicit statement that return will pop cancellation handlers and
the overview is explicitly stating that it does not. If the standard is
interpreted as is being done by the test suite, the standard is in conflict
with itself. (POSIX.1, subclause 18.2.3.2 (P352, L206-210) and the
corresponding rationale in subclause B.18.2.3 (P581-582, L9294-9319) clearly
say that pthread_cleanup_push() and pthread_cleanup_pop() can be
implemented as macros and even give a sample implementation, but the way
the test suite interprets subclause 16.2.5.2 (P339-340, L229-242)
clearly precludes a macro implementation.)Test Output
400|0 3 1 20:12:15|IC Start
200|0 3 20:12:15|TP Start
520|0 3 00013731 1 1|An implicit call to pthread_exit() is made when a thread
other 520|0 3 00013731 1 2|than the thread in which main() was first invoked
returns from 520|0 3 00013731 1 3|the start routine that was used to create
it. 520|0 3 00013731 1 4|Posix Ref: Component PTHREAD_EXIT
520|0 3 00013731 1 5|Assertion 9945-1:1996 16.2.5.2-3(A)
520|0 3 00013731 2 1|T3_cflag, expected 2, got 0
220|0 3 1 20:12:15|FAIL
410|0 3 1 20:12:15|IC EndReview Information
Review Type TSMA Review Start Date null Completed null Status Complete Review Recommendation No Resolution Given Review Response
We agree with the applicant's assertion that POSIX.1-1996 requires
pthread_cleanup_push() and pthread_cleanup_pop() to be used in the
same lexical scope and that POSIX.1 allows these functions to
be implemented as macros. However, we disagree with the applicant's
assertion that this prevents an application from performing a
return from within this lexical scope when a cancellation handler
is registered for the thread. No such explicit or implicit statement
is made by POSIX.1 and such a restriction would be counter-intuitive
to an application programmer in the absence of a specific restriction.
We recommend that a TIN be granted while this request be submitted
for an independent review.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution No Resolution Given Review Conclusion
We will submit a POSIX interpretation request.
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Temporary Interpretation (TIN) Review Conclusion
A Temporary Interpretation is granted.
Problem Reporting System Options:
- View Report 2031
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority