Document: N1554
Date: 01-Mar-11





Balloted document: N4578




Vote: Approve
NB
(ISO 3166)
No. Category Clause, Sub-clause Paragraph, Figure, Table Comment and rationale Proposed new text
AG 1 TL 7.22.4.7 page 352 para 2 Since quick_exit() disallows signal handlers to be called, what happens if a signal corresponding to a computational exception is generated during execution of one of the functions registered by at_quick_exit()? Add a statement that the behaviour is undefined.
AG 2 TL 7.25.1 The xtime structure page 374 para 4 POSIX already defines two different structures to hold time, one of which, struct timespec, is almost identical to the xtime structure. It would be appropriate to merge the xtime and timespec structures. Remove xtime from thrd.h
Change para 3 of <time.h> from
"... which are arithmetic types capable of representing times; and
struct tm
which holds the components of a calendar time, called the broken-down time."

To:
" which are arithmetic types capable of representing times;
struct timespec
which is a structure type that holds a time specified in seconds and nanoseconds. The structure shall contain at least the following members, in any order.
time_t tv_sec; long tv_nsec;
and
struct tm
which holds the components of a calendar time, called the broken-down time."

Globally replace "xtime" with "timespec", the "sec" member with "tv_sec, and the "nsec" member with "tv_nsec". [Note the remainder of this ballot uses xtime where appropriate. The global edit suggested here should be applied to these ballot comments if this comment is accepted]
AG 3 TL 7.25.3.5 The cnd_timedwait function page 376 para 1,2 "until after the time specified by the xtime object pointed to by xt"

It is not clear whether xt specifies an absolute time or elapsed
time from the start of the cnd_timedwait() call.

I.e should applications just set xt to the length of the timeout,
or should they call xtime_get(), add the length to the returned
time, and then use that.

The equivalent POSIX function pthread_cond_timedwait() takes an
absolute time. There are good reasons for this: see the RATIONALE in
the POSIX description of the function.
Clarify whether xt is an absolute time or the length of the timeout.
AG 4 TL 7.25.3.6 The cnd_wait function page 377 para 2 "If the mutex pointed to by mtx is not locked by the calling thread,
the cnd_wait function will act as if the abort function is called."

This requirement means mutexes must keep a record of ownership,
which affects efficiency, and is inconsistent with cnd_timedwait()
whose description states "The cnd_timedwait function requires that
the mutex pointed to by mtx be locked by the calling thread."

Change

"If the mutex pointed to by mtx is not locked by the calling thread,
the cnd_wait function will act as if the abort function is called."

to

"The cnd_wait function requires that the mutex pointed to by mtx
be locked by the calling thread."
AG 5 TL 7.25.4.4 The mtx_timedlock function page 379 para 2 "until the time specified by the xtime object xt has passed"

It is not clear whether xt specifies an absolute time, or elapsed
time from the start of the mtx_timedlock() call.

I.e should applications just set xt to the length of the timeout,
or should they call xtime_get(), add the length to the returned
time, and then use that.

The equivalent POSIX function pthread_mutex_timedlock() takes an
absolute time.

It would also make sense for mtx_timedlock() to be consistent with
cnd_timedwait() in this regard. (The same issue has been reported
separately for cnd_timedwait().)
Clarify whether xt is an absolute time or the length of the timeout.
AG 6 TL 7.25.5.5 The thrd_exit function page 381 para 2 Nothing is said about what happens if the last thread left running
calls thrd_exit(). POSIX has the following requirement for the
equivalent pthread_exit() function:

"The process shall exit with an exit status of 0 after the last
thread has been terminated. The behavior shall be as if the
implementation called exit() with a zero argument at thread
termination time."

The C Standard should either require this behaviour, or should allow
this behaviour and one or more other behaviours (and say the behaviour
is implementation-defined).
Add a statement about the program terminating as if by a call
to exit(0) after the last thread has terminated execution.
AG 7 TL 7.25.5.7 The thrd_sleep function page 382 para 2 "until after the time specified by the xtime object pointed to by xt"

It is not clear whether xt specifies an absolute time, or elapsed
time from the start of the thrd_sleep() call. Presumably it is
intended to be elapsed time.
Clarify that xt specifies elapsed time.
AG 8 TL 7.25.5.7 The thrd_sleep function page 382 para 2 What happens if a signal handler is executed during execution
of the thrd_sleep function? Does it return prematurely, or
continue sleeping? If it returns prematurely, it would be
useful for it to indicate the remaining sleep time.

The equivalent POSIX function nanosleep() returns prematurely,
and places the remaining time in an object pointed to by a second
argument.
Either

1. specify that execution of a signal handler does not cause
thrd_sleep to return prematurely, or

2. change the return type and/or arguments so that the remaining time
can be returned to the caller; state that if execution of a signal
handler interrupts thrd_sleep then it returns immediately; and
describe how the function indicates whether it was interrupted and
what the remaining time is.
AG 9 TL 7.25.7.1 The xtime_get function page 384 para 1 See also AG 2 -- Since xtime_get() is useful in its own right, not just with threads,
it would be better for xtime_get() to be declared in <time.h> instead
of <threads.h>. (Putting it in <time.h> would also mean xtime_get()
becomes mandatory; if it is desirable for it to be optional, an
alternative would be to have a new optional <xtime.h> header and put
it in there.)
Move the declaration/description of the xtime type and the declaration
of xtime_get() from <threads.h> to <time.h>. In <threads.h> require that
it declare the xtime type and refer to <time.h> "(described in 7.26)".
AG 10 TL 7.25.7.1 The xtime_get function page 384 para 2 "sets the xtime object pointed to by xt to hold the current time"

Since xtime represents time in seconds and nanoseconds, the "current
time" here must be the number of seconds since a certain epoch, but
nothing is stated about this epoch.
Either the epoch should be specified as a fixed time in the past
(such as 1970-01-01T00:00:00 UTC as in POSIX) or the standard should
state that the epoch is implementation-defined.
AG 11 TL 7.25.7.1 The xtime_get function 7.25.7.1 The xtime_get function
This paragraph says that the value of base must be TIME_UTC, but
TIME_UTC is not defined anywhere.
Add a requirement for TIME_UTC to be defined as a macro in the same
header that xtime_get() and the xtime type are declared in. (I.e. in
<threads.h> unless the latter are moved to a different header.)