Minutes of the 19th September 2013 Teleconference Austin-627 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 20th September 2013
Attendees
Don Cragun, PASC OR
Geoff Clare, The Open Group
Eric Blake, Red Hat
Andrew Josey, The Open Group
Mark Brown
David Clissold, IBM
Nick Stoughton, USENIX, ISO/IEC OR
Joerg Schilling, Fraunhofer Society
Richard Hansen, BBN
Apologies
Mark Ziegast
* General news
No news.
* Outstanding actions
+Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN
http://austingroupbugs.net/view.php?id=251
Don has an action to produce a proposal.
+Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN
http://austingroupbugs.net/view.php?id=561
Eric has an action to update the proposal.
+Bug 0000573: Please add '+' to the portable filename character set OPEN
http://austingroupbugs.net/view.php?id=573
Joerg has an action to prepare a proposed change.
+Bug 0000592: consistent use of struct timespec OPEN
http://austingroupbugs.net/view.php?id=592
Jim had provided additional information in bugnote 1627.
This was discussed and Jim took an action to provide further information.
+Bug 0000598: OH shading and new interfaces OPEN
http://austingroupbugs.net/view.php?id=598
Eric has an action to propose a new solution with self-contained headers.
+Bug 0000517: EBNF support OPEN
http://austingroupbugs.net/view.php?id=517
Action on Joerg to look at this.
+Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe
OPEN
http://austingroupbugs.net/view.php?id=633
We noted that feedback has settled down on the mailing list, and
will discuss next session.
+Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer
are insufficiently specified OPEN
http://austingroupbugs.net/view.php?id=657
Eric has an action to propose wording to clarify the behavior for
fmemopen(), and also to contact the glibc developers to get their
feedback.
+Bug 0000658: Undefined/unspecified behavior clauses in description of
open have race conditions OPEN
http://austingroupbugs.net/view.php?id=658
It was noted that there is some overlap with changes in TC1. Eric took an
action to update the proposal to resolve the overlaps appropriately.
+Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
We now have reports on AIX and Apple. Jim to report back on whether
pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask
HP whether pthread_cancelstate() is async-signal-safe on HP-UX.
+Bug 622 left open pending resolution of 615.
http://austingroupbugs.net/view.php?id=622
+Bug 0000672: Necessary step(s) to synchronize filename operations on disk
OPEN
http://austingroupbugs.net/view.php?id=672
Geoff has a new proposed resolution in note 1618. Decided to solicit input
from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris.
Jim has completed his action (see bugnote 1691).
Andrew should chase HP and Apple for input.
+Bug 0000663: Specification of str[n]casecmp is ambiguous reopened
http://austingroupbugs.net/view.php?id=663
Action on David to follow up with the IBM developers about the EBCDIC
collation sequence.
Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification
http://www.austingroupbugs.net/view.php?id=696
Don has an action to propose a resolution.
Bug 0000721: Internal storage vs static storage OPEN
http://austingroupbugs.net/view.php?id=721
This item is still open.
* Current Business
Bug 0000741: Add a NSIG constant (or, alternatively, SIGMAX) Accepted as Marked
http://austingroupbugs.net/view.php?id=741
Note 1834 was updated as a result of feedback and discussions
on the mailing list during the week.
Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375
This item is related to list discussion on 4-argument test (mail
sequence 19739)
Action: Andrew to ask David Korn to review proposal in bug 375, and
how it relates to test
http://austingroupbugs.net/file_download.php?file_id=15&type=bug
Bug 0000714: yn(n,0) is incorrect for odd n<0 Accepted as Marked.
http://austingroupbugs.net/view.php?id=714
Bug note 1835 has been updated to match list discussion
This item requires an interpretation and is ready to be proposed
with the next batch of interpretations.
Bug 0000743: RAND_MAX should guarantee even distribution over a power of 2 Accepted as Marked
http://austingroupbugs.net/view.php?id=743
This item is tagged for TC2-2008
In rand() on P1749 L56250, change:
The drand48( ) function provides a much more elaborate random
number generator.
to:
The drand48() and random() functions provide much more elaborate
pseudo-random number generators.
On P1749, L56253-56254, change:
Therefore this function should be avoided whenever non-trivial
requirements (including safety) have to be fulfilled.
to a new paragraph:
These functions should be avoided whenever non-trivial requirements
(including safety) have to be fulfilled.
In P1750, L56273 "see also" section, add random()
In drand48() on P744 L25096 application usage, change "none" to:
These functions should be avoided whenever non-trivial requirements
(including safety) have to be fulfilled.
In P744 L25102 "see also" section of drand48(), add random()
In initstate() on P1128 add a new paragraph after L37891:
These functions should be avoided whenever non-trivial requirements
(including safety) have to be fulfilled.
Bug 0000690: clarify behavior when calling waitpid with SA_NOCLDWAIT Accepted as Marked
http://www.austingroupbugs.net/view.php?id=690
(this item should reopened)
Email discussion: http://thread.gmane.org/gmane.comp.standards.posix.austin.general/8095
Proposed changes to the proposed change: http://posix.rhansen.org:9001/p/bug690
This will be discussed next week.
Bug #690
http://www.austingroupbugs.net/view.php?id=690
Proposed changes:
After Issue7+TC1 XBD section 3.209 ("Link Count") page 66 line 1935,
insert a new section 3.210 Live Process whose contents are copied
from Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275
and renumber the subsequent sections.
At Issue7+TC1 XBD section 3.291 ("Process") page 80 lines 2269-2275, change:
An address space with one or more threads executing within that
address space, and the required system resources for those
threads.
Note: Many of the system resources defined by POSIX.1-2008
are shared among all of the threads within a process. These
include the process ID, the parent process ID, process group
ID, session membership, real, effective, and saved set-user-ID,
real, effective, and saved set-group-ID, supplementary group
IDs, current working directory, root directory, file mode
creation mask, and file descriptors.
to:
A live process (see Section 3.210) or a zombie process (see
Section 3.447). The lifetime of a process is described in
Section 3.298.
Note that the new text uses the adjusted section numbers.
At Issue7+TC1 XBD section 3.297 ("Process Lifetime") page 81 lines 2295-2304, change:
The period of time that begins when a process is created and
ends when its process ID is returned to the system. After a
process is created by fork(), posix_spawn(), or posix_spawnp(),
it is considered active. At least one thread of control and
address space exist until it terminates. It then enters an
inactive state where certain resources may be returned to the
system, although some resources, such as the process ID, are
still in use. When another process executes a wait(), waitid(),
or waitpid() function for an inactive process, the remaining
resources are returned to the system. The last resource to be
returned to the system is the process ID. At this time, the
lifetime of the process ends.
Note: The fork(), posix_spawn(), posix_spawnp(), wait(),
waitid(), and waitpid() functions are defined in detail in the
System Interfaces volume of POSIX.1-2008.
to:
The period of time that begins when a process is created and
ends when its process ID is returned to the system.
See also Live Process in Section 3.210, Process Termination in
Section 3.300, and Zombie Process in Section 3.447.
Note: Process creation is defined in detail in the
descriptions of the fork(), posix_spawn(), and posix_spawnp()
functions in the System Interfaces volume of POSIX.1-2008.
Note that the new text uses the adjusted section numbers.
At Issue7+TC1 XBD section 3.299 ("Process Termination") page 81 lines 2318-2319, change:
Note: The _exit(), _Exit(), abort(), and exit() functions
are defined in detail in the System Interfaces volume of
POSIX.1-2008.
to:
Note: The consequences of process termination can be
found in the description of the _Exit() function in the System
Interfaces volume of POSIX.1-2008. The _exit(), _Exit(),
abort(), and exit() functions are defined in detail in the
System Interfaces volume of POSIX.1-2008.
At Issue7+TC1 XBD section 3.446 ("Zombie Process") page 105 lines 2871-2872, change:
A process that has terminated and that is deleted when its exit
status has been reported to another process which is waiting
for that process to terminate.
to:
The remains of a live process (see Section 3.210) after it
terminates (see Section 3.300) and before its status information
(see XSH Section 2.13) is consumed by its parent process.
Note that the new text uses the adjusted section numbers.
After Issue7+TC1 XSH section 2.12 page 546 line 19012, insert:
2.13 Status Information
Status information is data associated with a process detailing
a change in the state of the process. It shall consist of:
The state the process transitioned into ('stopped', 'continued',
or 'terminated').
The information necessary to populate the siginfo_t structure
provided by waitid().
If the new state is 'terminated':
The low-order 8 bits of the status argument that the process
passed to _Exit(), _exit(), or exit(), or the low-order 8 bits
of the value the process returned from main(). Note that these
8 bits are part of the complete value that is used to set the
si_status member of the siginfo_t structure provided by waitid().
Whether the process terminated due to the receipt of a signal
that was not caught, and if so, the number of the signal that
caused the termination of the process.
If the new state is 'stopped':
The number of the signal that caused the process to stop.
A process might not have any status information (such as
immediately after a process has started).
Status information for a process shall be generated (made
available to the parent process) when a the process stops,
continues, or terminates except in the following case:
If the parent process sets the action for the SIGCHLD signal
to SIG_IGN, or if the parent sets the SA_NOCLDWAIT flag for the
SIGCHLD signal action, process termination shall not generate
new status information but shall cause any existing status
information for the process to be discarded.
If new status information is generated, and the process already
had status information, the existing status information shall
be discarded and replaced with the new status information.
Only the process's parent process can obtain the process's
status information. The parent obtains a child's status
information by calling wait(), waitid(), or waitpid().
Except when waitid() is called with the WNOWAIT flag set in the
options argument, the status information made available to
obtained by a wait function shall be consumed (discarded) by
that wait function; no two calls to wait(), waitid() (without
WNOWAIT), or waitpid() shall obtain the same status information.
When status information becomes available to the parent process
and more than one thread in the parent process is waiting for
the status information (blocked in a call to wait(), waitid(),
or waitpid() with arguments that would match the status
information):
If none of those the matching threads is in a call to waitid()
with the WNOWAIT flag set in the options argument, the thread
that obtains the status information is unspecified.
Otherwise (at least one of the matching threads is in a call
to waitid() with the WNOWAIT flag set), the matching thread or
threads that obtain the status information is unspecified except
that at least one of those the matching threads shall obtain
the status information and at most one of those the matching
threads that are not calling waitid() with the WNOWAIT flag set
shall obtain it.
and renumber the subsequent sections.
At Issue7+TC1 XBD chapter 13 page 334 line 11158, change:
[CX]SA_NOCLDWAIT Causes implementations not to create zombie
processes on child death.[/CX]
to:
[XSI]SA_NOCLDWAIT Causes implementations not to create zombie
processes or status information on child termination. See
sigaction(), page 1932.[/XSI]
Note the change from CX shading to XSI shading.
At Issue7+TC1 XSH section 2.4.3 page 491 lines 16773-16779, change:
If a process sets the action for the SIGCHLD signal to SIG_IGN,
the behavior is unspecified, [XSI]except as specified below.
If the action for the SIGCHLD signal is set to SIG_IGN, child
processes of the calling processes shall not be transformed
into zombie processes when they terminate. If the calling
process subsequently waits for its children, and the process
has no unwaited-for children that were transformed into zombie
processes, it shall block until all of its children terminate,
and wait(), waitid(), and waitpid() shall fail and set errno
to [ECHILD].[/XSI]
to:
If a process sets the action for the SIGCHLD signal to SIG_IGN,
the behavior is unspecified[XSI], except as specified under
"Consequences of Process Termination" in the description of the
_Exit() function on page 549[/XSI].
At Issue7+TC1 XSH chapter 3 (description of _Exit() and _exit(),
"Consequences of Process Termination") pages 549-550 lines 19051-19072,
after applying the changes in 0000594, change:
If the parent process of the calling process is executing a
wait(), waitid(), or waitpid(), [XSI]and has neither set its
SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] it shall
be notified of termination of the calling process and the child's
status shall be made available to it. If the parent is not
waiting, the child's status shall be made available to it when
the parent subsequently executes wait(), waitid(), or waitpid().
If the parent process of the calling process is not executing
a wait(), waitid(), or waitpid(), [XSI]and has neither set its
SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN,[/XSI] the calling
process shall be transformed into a zombie process. A zombie
process is an inactive process and it shall be deleted at some
later time when its parent process executes wait(), waitid(),
or waitpid().
Termination of a process does not directly terminate its children.
The sending of a SIGHUP signal as described below indirectly
terminates children in some circumstances.
Either:
If the implementation supports the SIGCHLD signal, a SIGCHLD
shall be sent to the parent process.
Or:
[XSI]If the parent process has set its SA_NOCLDWAIT flag, or
set SIGCHLD to SIG_IGN, the status shall be discarded, and the
lifetime of the calling process shall end immediately. If
SA_NOCLDWAIT is set, it is implementation-defined whether a
SIGCHLD signal is sent to the parent process.[/XSI]
to:
[XSI]If the parent process of the calling process has set its
SA_NOCLDWAIT flag or has set the action for the SIGCHLD signal
to SIG_IGN:
The process's status information (see XSH Section 2.13), if
any, shall be discarded.
The lifetime of the calling process shall end immediately. If
SA_NOCLDWAIT is set, it is implementation-defined whether a
SIGCHLD signal is sent to the parent process.
If a thread in the parent process of the calling process is
blocked in wait(), waitpid(), or waitid(), and the parent process
has no remaining child processes in the set of waited-for
children, the wait(), waitid(), or waitpid() function shall
fail and set errno to [ECHILD].
Otherwise:[/XSI]
Status information (see XSH Section 2.13) shall be generated.
The calling process shall be transformed into a zombie process.
Its status information shall be made available to the parent
process until the process's lifetime ends.
The process's lifetime shall end once its parent obtains the
process's status information via a currently-blocked or future
call to wait(), waitid() (without WNOWAIT), or waitpid().
If one or more threads in the parent process of the calling
process is blocked in a call to wait(), waitid(), or waitpid()
awaiting termination of the process, one (or, if any are calling
waitid() with WNOWAIT, possibly more) of these threads shall
obtain the process's status information as specified in XSH
Section 2.13 and become unblocked.
A SIGCHLD shall be sent to the parent process.
Termination of a process does not directly terminate its children.
The sending of a SIGHUP signal as described below indirectly
terminates children in some circumstances.
At Issue7+TC1 XSH chapter 3 sigaction() description page 1932 lines
61931-61938, change:
SA_NOCLDWAIT: If set, and sig equals SIGCHLD, child processes
of the calling processes shall not be transformed into zombie
processes when they terminate. If the calling process subsequently
waits for its children, and the process has no unwaited-for
children that were transformed into zombie processes, it shall
block until all of its children terminate, and wait(), waitid(),
and waitpid() shall fail and set errno to [ECHILD]. Otherwise,
terminating child processes shall be transformed into zombie
processes, unless SIGCHLD is set to SIG_IGN.
to:
[XSI]SA_NOCLDWAIT: If sig does not equal SIGCHLD, the behavior
is unspecified. Otherwise, the behavior of the SA_NOCLDWAIT
flag is as specified under "Consequences of Process Termination"
in the description of the _Exit() function on page 549.[/XSI]
Note the addition of XSI shading, which I believe was an omission.
At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page
2203 lines 69847-69856, change:
The wait() and waitpid() functions shall obtain status information
pertaining to one of the caller's child processes. Various
options permit status information to be obtained for child
processes that have terminated or stopped. If status information
is available for two or more child processes, the order in which
their status is reported is unspecified.
The wait() function shall suspend execution of the calling
thread until status information for one of the terminated child
processes of the calling process is available, or until delivery
of a signal whose action is either to execute a signal-catching
function or to terminate the process. If more than one thread
is suspended in wait() or waitpid() awaiting termination of the
same process, exactly one thread shall return the process status
at the time of the target process termination. If status
information is available prior to the call to wait(), return
shall be immediate.
to:
The wait() and waitpid() functions shall obtain status information
(see XSH Section 2.13) pertaining to one of the caller's child
processes. The wait() function obtains status information for
process termination from any child process. The waitpid()
function obtains status information for process termination,
and optionally process stop and/or continue, from a specified
subset of the child processes.
The wait() function shall cause the calling thread to become
blocked until status information generated by child process
termination is made available to the thread, or until delivery
of a signal whose action is either to execute a signal-catching
function or to terminate the process, or an error occurs. If
termination status information is available prior to the call
to wait(), return shall be immediate. If termination status
information is available for two or more child processes, the
order in which their status is reported is unspecified.
As described in XSH Section 2.13, the wait() and waitpid()
functions consume the status information they obtain.
The behavior when multiple threads are blocked in wait(),
waitid(), or waitpid() is described in XSH Section 2.13.
At Issue7+TC1 XSH chapter 3 wait() and waitpid() description page
2203 lines 69881-69884, remove:
[XSI]If the calling process has SA_NOCLDWAIT set or has SIGCHLD
set to SIG_IGN, and the process has no unwaited-for children
that were transformed into zombie processes, the calling thread
shall block until all of the children of the process containing
the calling thread terminate, and wait() and waitpid() shall
fail and set errno to [ECHILD].[/XSI]
After Issue7+TC1 XSH chapter 3 wait() and waitpid() application
usage page 2208 after line 70110, insert:
[XSI]As specified under "Consequences of Process Termination"
in the description of the _Exit() function on page 549, if the
calling process has SA_NOCLDWAIT set or has SIGCHLD set to
SIG_IGN, then the termination of a child process will not cause
status information to become available to a thread blocked in
wait(), waitid(), or waitpid(). Thus, a thread blocked in one
of the wait functions will remain blocked unless some other
condition causes the thread to resume execution (such as an
[ECHILD] failure due to no remaining children in the set of
waited-for children).[/XSI]
At Issue7+TC1 XSH chapter 3 waitid() description page 2212 lines
70244-70250, change:
The waitid() function shall suspend the calling thread until
one child of the process containing the calling thread changes
state. It records the current state of a child in the structure
pointed to by infop. The fields of the structure pointed to
by infop are filled in as described for the SIGCHLD signal in
. If a child process changed state prior to the call
to waitid(), waitid() shall return immediately. If more than
one thread is suspended in wait(), waitid(), or waitpid() waiting
for termination of the same process, exactly one thread shall
return the process status at the time of the target process
termination.
to:
The waitid() function shall obtain status information (see XSH
Section 2.13) pertaining to termination, stop, and/or continue
events in one of the caller's child processes.
The waitid() function shall cause the calling thread to become
blocked until an error occurs or status information becomes
available to the calling thread that satisfies all of the
following properties ("matching status information"):
The status information is from one of the child processes in
the set of child processes specified by the idtype and id
arguments.
The state change in the status information matches one of the
state change flags set in the options argument.
If matching status information is available prior to the call
to waitid(), return shall be immediate. If matching status
information is available for two or more child processes, the
order in which their status is reported is unspecified.
As described in XSH Section 2.13, the waitid() function consumes
the status information it obtains unless the WNOWAIT flag is
set in the options argument.
The behavior when multiple threads are blocked in wait(),
waitid(), or waitpid() is described in XSH Section 2.13.
The waitid() function shall record the obtained status information
in the structure pointed to by infop. The fields of the structure
pointed to by infop shall be filled in as described under
"Pointer to a Function" in Section 2.4.3 on page 492.
After Issue7+TC1 XSH chapter 3 waitpid() application usage at page
2213 line 70293, insert:
[XSI]As specified under "Consequences of Process Termination"
in the description of the _Exit() function on page 549, if the
calling process has SA_NOCLDWAIT set or has SIGCHLD set to
SIG_IGN, then the termination of a child process will not cause
status information to become available to a thread blocked in
wait(), waitid(), or waitpid(). Thus, a thread blocked in one
of the wait functions will remain blocked unless some other
condition causes the thread to resume execution (such as an
[ECHILD] failure due to no remaining children in the set of
waited-for children).[/XSI]
After Issue7+TC1 XRAT section B.2.12.3 page 3649 line 124639, insert:
B.2.13 Status Information
POSIX.1-2008 does not require all matching WNOWAIT threads
(threads in a matching call to waitid() with the WNOWAIT flag
set) to obtain a child's status information because the status
information might be discarded (consumed or replaced) before
one of the matching WNOWAIT threads is scheduled. If the status
information is not discarded, it will remain available, so all
of the matching WNOWAIT threads will (eventually) obtain the
status information.
Next Steps
----------
The next call is on September 26, 2013 (a Thursday)
Calls are anchored on US time.
This call will be for the regular 90 minutes.
http://austingroupbugs.net
An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs
We are now using an Etherpad for note taking
- the URL is given at the start of the meeting in IRC