Minutes of the 20 December 2012 Teleconference Austin-589 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 22 December, 2012 Attendees Mark Brown, IBM, TOG OR Don Cragun, PASC OR Andrew Josey, The Open Group Geoff Clare, The Open Group Eric Blake, Red Hat Joerg Schilling, Fraunhofer Society Jim Pugsley, Oracle Nick Stoughton, USENIX, ISO/IEC OR * General News Mark reported that he was having to block some IP addresses accessing the bug tracker due to abuse , and if anyone has difficulties to let him know. * 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 at 633 Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 This item was left open. 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)? Jim has reported back two meetings back (circulated to Austin Core). Mark reported that he needed more time. Bug 0000632: Side effects of pclose on cancellation are not specified OPEN http://austingroupbugs.net/view.php?id=632 This is being left open for feedback. Bug 0000625: Allowing alarm-based sleep() implementation contradicts requirement of thread-safety Accepted as Marked http://austingroupbugs.net/view.php?id=625 This item is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The standard does not adequately address the differences between single-threaded and multi-threaded processes and programs. Notes to the Editor (not part of this interpretation): Add a new paragraph after page 1963 line 62339: In single-threaded programs, sleep() may make use of SIGALRM. In multi-threaded programs, sleep() shall not make use of SIGALRM and the remainder of this DESCRIPTION does not apply. On page 1963 line 62369 in the RATIONALE change: This volume of POSIX.1-2008 permits either approach. to This volume of POSIX.1-2008 permits either approach in single-threaded programs, but the simple alarm/suspend implementation is not appropriate for multi-threaded programs. On page 1964 line 62406 change the FUTURE DIRECTIONS section from: None. to: A future version of this standard may require that sleep() does not make use of SIGALRM in all programs, not just multi-threaded programs. Cross-volume changes to XBD... Add the following definitions in XBD chapter 3, in alphabetical order: Multi-threaded library A library containing object files that were produced by compiling with c99 using the flags output by getconf POSIX_V7_THREADS_CFLAGS, or by compiling using a non-standard utility with equivalent flags, and which makes use of interfaces that are only made available by c99 when the -l pthread option is used or makes use of SIGEV_THREAD notifications. Multi-threaded process A process that contains more than one thread. Multi-threaded program A program whose executable file was produced by compiling with c99 using the flags output by getconf POSIX_V7_THREADS_CFLAGS, and linking with c99 using the flags output by getconf POSIX_V7_THREADS_LDFLAGS and the -l pthread option, or by compiling and linking using a non-standard utility with equivalent flags. Execution of a multi-threaded program initially creates a single-threaded process; the process can create additional threads using pthread_create() or SIGEV_THREAD notifications. Single-threaded process A process that contains a single thread. Single-threaded program A program whose executable file was produced by compiling with c99 without using the flags output by getconf POSIX_V7_THREADS_CFLAGS and linking with c99 using neither the flags output by getconf POSIX_V7_THREADS_LDFLAGS nor the -l pthread option, or by compiling and linking using a non-standard utility with equivalent flags. Execution of a single-threaded program creates a single-threaded process; if the process attempts to create additional threads using pthread_create() or SIGEV_THREAD notifications, the behavior is undefined. If the process uses dlopen() to load a multi-threaded library, the behavior is undefined. Bug 0000635: Clarify that uudecode ignores chmod() errors Accepted http://austingroupbugs.net/view.php?id=635 This item is tagged for TC2-2008. An interpretation is required. Interpretation response: The standard states that an error has to be raised if the mode change fails, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The current standard does not match existing (and desired) behavior. Notes to the Editor (not part of this interpretation): Make the suggested changes. Bug 0000636: Page missing Accepted http://austingroupbugs.net/view.php?id=636 This has now been fixed in the onlinepubs, but the source document needs to be recoded to avoid the link being generated erroneously in the future. Bug 0000624: pthread_cleanup_pop and _push should be macro only Accepted as Marked http://austingroupbugs.net/view.php?id=624 This item is tagged for TC2-2008 An interpretation is required Interpretation response: The standard states that pthread_cleanup_push and pthread_cleanup_pop shall be implemented as functions as well as macros, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Existing implementations exclusively implement these functions as function-like macros, and do not provide any underlying function. The application usage and rationale provided show an implementation that only works as a macro. Notes to the Editor (not part of this interpretation): Page 1574 line 50552 change "These functions may be implemented as macros. " to: It is unspecified whether pthread_cleanup_push and pthread_cleanup_pop are macros or functions. If a macro definition is suppressed in order to access an actual function, or a program defines an external identifier with any of these names the behavior is undefined. Cross Volume change to XBD, page 312 lines 10448 and 10449: delete pthread_cleanup_push and pthread_cleanup_pop from this list. Add a new paragraph after line 10542: The following may be declared as functions, or defined as macros, or both. If functions are declared, function prototypes shall be provided. pthread_cleanup_pop pthread_cleanup_push Next Steps ---------- The next call is on January 10 2013 (a Thursday) 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