Minutes of the 28 November 2012 Teleconference Austin-586 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 29 November, 2012 Attendees Don Cragun, PASC OR Andrew Josey, The Open Group (partial) Geoff Clare, The Open Group Eric Blake, Red Hat Joerg Schilling, Fraunhofer Society Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Nathan Weeks, Iowa State University (partial) Jim Pugsley, Oracle * General News Andrew reported that TC1 has been withdrawn from the December IEEE RevCom agenda and that another recirculation has been started with the Base Standard being included this time. This is a 10 day review. * Old Business +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 This item needs further investigation of existing implementations. Mark reported that AIX does not have a problem with this. Jim notes he is still looking at this. +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 0000576: No format specifiers for several types OPEN http://austingroupbugs.net/view.php?id=576 Bug 0000599: Reserved "no thread" value for pthread_t A/M Issue 8 Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 It was agreed that we need Joerg's input on this item and have left it open for now. Andrew took an action on the 12 September call to notify Joerg (completed after the meeting). * Current Business We picked up again at bug 628 Bug 0000628: subsequent execution of semaphore operations for a semop() of a thread suspended during semop() with sem_op == 0 Accepted as Marked http://austingroupbugs.net/view.php?id=628 Nathan Weeks joined the call to discuss further bug 628 and semop() behavior. We have not yet updated the bug. Don agreed to take an action that takes into account input from Geoff on austin-core-l mail seq 339. Bug 0000627: Behavior of system() when cancelled is not specified Accepted as Marked http://austingroupbugs.net/view.php?id=627 Geoff had completed his action to propose a response. An interpretation is required. This item is tagged for TC2-2008 Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The system() function is not required to be thread-safe, yet the standard requires a cancellation point to occur when executing it. Notes to the Editor (not part of this interpretation): At page 512 line 17704 section 2.9.5.2, remove "system()" from the list of mandatory cancellation points. On page 513-514 lines 17715-17789 section 2.9.5.2, remove all of the following functions (which are not required to be thread-safe) from the list of optional cancellation points: asctime endutxent getopt getutxid catgets ftw getprotobyname getutxline ctime getdate getprotobynumber localtime dbm_close getgrent getprotoent nftw dbm_delete getgrgid getpwent pututxline dbm_fetch getgrnam getpwnam readdir dbm_nextkey gethostent getpwuid setgrent dbm_open getlogin getservbyname setpwent dbm_store getnetbyaddr getservbyport setutxent endgrent getnetbyname getservent strerror endpwent getnetent getutxent ttyname After page 514 line 17789 section 2.9.5.2, add a new paragraph after the list of optional cancellation points: In addition, a cancellation point may occur when a thread is executing any function that this standard does not require to be thread-safe but the implementation documents as being thread-safe. If a thread is cancelled while executing a non-thread-safe function, the behavior is undefined. After page 2072 line 65661 section system(), add a new paragraph to the RATIONALE section: Note also that the above example implementation is not thread-safe. Implementations can provide a thread-safe system() function, but doing so involves complications such as how to restore the signal dispositions for SIGINT and SIGQUIT correctly if there are overlapping calls, and how to deal with cancellation. The example above would not restore the signal dispositions and would leak a process ID if cancelled. This does not matter for a non-thread-safe implementation since cancelling a non-thread-safe function results in undefined behavior (see [xref to 2.9.5.2]). To avoid leaking a process ID, a thread-safe implementation would need to terminate the child process when acting on a cancellation. Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 Mark and Jim took an action to report on the following aspects of AIX and Solaris behaviour for SIGEV_THREAD event notification (from timers, AIO, etc. - the answers might be different for each): 1. What is the signal mask in the thread that is created to handle the notification? (Is it just inherited from the calling thread?) 2. When an event notification is triggered and a previous handler is still executing, do they execute a new instance of the same handler concurrently, or suppress the new notification (or something else)? Action on Andrew to send email to his technical contacts at Apple and HP asking them the same question. Bug 0000632: Side effects of pclose on cancellation are not specified OPEN http://austingroupbugs.net/view.php?id=633 After a lengthy discussion we came to the conclusion that pclose() and cancellation do not mix. We considered leaving the normative text as-is and just adding application usage warning that applications should not cancel a thread that is executing pclose(), but we felt that was not strong enough. The direction we plan to take is for the normative text to state that if a thread is cancelled while it is executing pclose(), the behaviour is undefined. Next Steps ---------- The next call is on December 5 This call will be for the regular 90 minutes. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs