Defect report from : David Butenhof , Hewlett-Packard Company
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 295-297 line 9574-9665 section exec objection {drb.7.exec.threads}
Problem:
Defect code : 1. Error
The description of actions taken in response to a call to the exec()
family of functions does not properly account for threads.
Several actions have already been taken to improve this situation,
including the recent ERNs 9, 45, and 46. However, these do not
comprise a complete solution, and this aardvark strives to resolve
some additional problems.
ERN 46 added "catch all" text for "other thread attributes", along the
lines of what had already existed for "other process attributes".
However, there are some "other thread attributes" that require special
behavior.
1. There are some we want NOT to be inherited, and
2. there are others we don't want to REQUIRE be inherited though
there's no reason they need to be changed.
In the former category, for example (the one that started all this),
we don't want to require that the initial thread in the new process
inherit the stack (or even the stacksize attribute) from the calling
thread.
In the second category would be the thread ID (pthread_t) value. While
there's no particular reason the initial thread in the new process
image CAN'T retain the ID of the calling thread (they're only
meaningful within a process, and the values aren't specified), we
certainly don't want to require that it must.
Some of these are stated, or at least implied, elsewhere in the
standard, but they ought to appear here.
Action:
[Note: sections in {...}[THR] are shaded and marked THR.]
p 295, line 9574: replace
The state of the floating-point environment in the new process image
shall be set to the default.
with
The state of the floating-point environment in the new process image
{or in the initial thread of the new process image}[THR] shall be
set to the default.
p 295, lines 9587-9588: replace
After a successful call to any of the exec functions, any functions
previously registered by atexit() are no longer registered.
with
After a successful call to any of the exec functions, any functions
previously registered by atexit() {or pthread_atfork()}[THR] are no
longer registered.
p 296, lines 9612-9614: replace
{For the SCHED_FIFO and SCHED_RR scheduling policies, the policy and
priority settings shall not be changed by a call to an exec
function. For other scheduling policies, the policy and priority
settings on exec are implementation-defined.}[PS]
with
When the calling process image does not use the SCHED_FIFO,
SCHED_RR, or SCHED_SPORADIC scheduling policies, the scheduling
policy and parameters of the new process image and the initial
thread in that new process image are implementation defined. {When
the calling process image uses the SCHED_FIFO, SCHED_RR, or
SCHED_SPORADIC scheduling policies, the process policy and
scheduling parameter settings shall not be changed by a call to an
exec function.}[PS] {The initial thread in the new process image
shall inherit the process scheduling policy and parameters. It shall
have the default system contention scope, but shall inherit its
allocation domain from the calling process image.}[TPS]
[Note: the scheduling inheritance I expect may be controversial. In
particular there is room for discussion about how threaded process
should inherit scheduling attributes. I believe that contention scope
should be set to the (implementation defined) default because that
makes the exec-ed process (and all processes are exec-ed!) work as I
think most people expect. However, I think allocation domain (e.g.,
processor/RAD binding) ought to be inherited as it enables commonly
implemented commands like 'runon' which must by definition affect not
only themselves but the child processes they fork/exec. I added
SCHED_SPORADIC to the special list only because I see no reason that
it ought to have been omitted, and in consequence widened "priority"
to "scheduling parameters".]
Add following line 9638 (before the list that begins "The new process
shall inherit at least..."):
{The pthread_t value returned by pthread_self() in the initial thread
in the new process image is unspecified.}[THR]
{The size and location of the stack on which the initial thread in the
new process image runs is unspecified.}[THR] [Associated rationale: we
expect the initial thread to run on the "default process stack" but,
in particular, it should not be constrained to any stack attributes
inherited from the calling thread in the calling process image.]
{The initial thread in the new process image shall have its
cancellation type set to PTHREAD_CANCEL_DEFERRED and its cancellation
state set to PTHREAD_CANCEL_ENABLED.}[THR]
{The initial thread in the new process image shall have all
thread-specific data values set to NULL and all thread-specific data
keys shall be removed by the call to exec without running
destructors.}[THR]
{The initial thread in the new process image shall be joinable, as if
created with the detachstate attribute set to PTHREAD_CREATE_JOINABLE.}[THR]
p 297, line 9663-9665: replace
A call to any exec function from a process with more than one thread
shall result in all threads being terminated and the new executable
image being loaded and executed. No destructor functions shall be
called.
with
{A call to any exec function from a process with more than one
thread shall result in all threads being terminated and the new
executable image being loaded and executed. No destructor functions
or cleanup handlers shall be called.}[THR]
[Should this be shaded THR? It wasn't. On the one hand, it IS specific
to threads and shading does no harm. On the other hand, the normative
text cancels itself out without shading if there are no threads, since
without the THR option there cannot be more than one thread.]
|