Minutes of the 12 December 2012 Teleconference Austin-588 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 13 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 Andrew reported that the TC1 recirculation ballot had closed and the document is on the agenda for the January IEEE Revcom meeting. * 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 Don had circulated a proposal just prior to the call (to austin-core-l seq 349) An interpretation is required. The item is tagged for Issue 8 Interpretation response: The standard states on P1839, L58733-58735 that "the semop() function shall perform atomically a user-defined array of semaphore operations" but on P1839, L58759-58765 it says: The value of semval becomes greater than or equal to the absolute value of sem_op. When this occurs, the value of semncnt associated with the specified semaphore shall be decremented, the absolute value of sem_op shall be subtracted from semval and, if (sem_flg &SEM_UNDO) is non-zero, the absolute value of sem_op shall be added to the semadj value of the calling process for the specified semaphore. and P1840, L58783-58784 it says: The value of semval becomes 0, at which time the value of semzcnt associated with the specified semaphore shall be decremented. which require that the semaphore operations be acted on individually if initial conditions cause the array of semaphore operations to block. Conforming implementations must conform to these requirements. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The stated requirements can only be met by an implementation if each of the operations in the array of semaphore operations can be completed successfully without blocking when semop() is called or if there is only one semaphore operation in the array of semaphore operations. The original intent of semop() was to atomically complete the array of semaphore operations. If one of the operations in the array causes semop() to block, the entire array of operations should be attempted again when there is a change to the value of the semaphore that caused the call to block. Notes to the Editor (not part of this interpretation): Change the entire description of processing the array of sempahore operations in the DESCRIPTION section of semop() on P1839-1840, L58747-58793 to the following: If all of the semaphore operations complete successfully, semop() shall return 0. If a semaphore operation fails or blocks, all changes to semadj and semval values performed by completed semaphore operations in the array before the operation that failed or blocked shall be undone before semop() returns or blocks, respectively. When a semaphore operation blocks, the change to semncnt or semzcnt indicating which semphore operation blocked shall not be undone until the operation unblocks. For each operation in the array of semaphore operations, the variable sem_op specifies one of three semaphore operations: 1. If sem_op is a negative integer and the calling process has alter permission, one of the following shall occur: * If semval(see ) is greater than or equal to the absolute value of sem_op, the absolute value of sem_op shall be subtracted from semval. Also, if (sem_flg & SEM_UNDO) is non-zero, the absolute value of sem_op shall be added to the semadj value of the calling process for the specified semaphore. If this is not the last operation in the array of semaphore operations to be performed, processing shall continue with the next operation in the array. * If semval is less than the absolute value of sem_op and (sem_flg & IPC_NOWAIT) is non-zero, the operation shall fail with errno set to EAGAIN. * If semval is less than the absolute value of sem_op and (sem_flg & IPC_NOWAIT) is 0, semop() shall increment the semncnt associated with the specified semaphore and suspend execution of the calling thread (block) until one of the following conditions occurs: - The value of semval changes. When this occurs, the value of semncnt associated with the specified semaphore shall be decremented and the array of semaphore operations shall be reevaluated. - The semid for which the calling thread is awaiting action is removed from the system. When this occurs the operation shall fail with errno set to [EIDRM]. - The calling thread receives a signal that is to be caught. When this occurs, the value of semncnt associated with the specified semaphore shall be decremented, and the calling thread shall resume execution in the manner prescribed in sigaction(). 2. If sem_op is a positive integer and the calling process has alter permission, the value of sem_op shall be added to semval and, if (sem_flg & SEM_UNDO) is non-zero, the value of sem_op shall be subtracted from the semadj value of the calling process for the specified semaphore. If this is not the last operation in the array of semaphore operations to be performed, processing shall continue with the next operation in the array. 3. If sem_op is 0 and the calling process has read permission, one of the following shall occur: * If semval is 0, this is a successful operation. If this is not the last operation in the array of semaphore operations to be performed, processing shall continue with the next operation in the array. * If semval is non-zero and (sem_flg & IPC_NOWAIT) is non-zero, the operation shall fail with errno set to EAGAIN. * If semval is non-zero and (sem_flg & IPC_NOWAIT) is 0, semop() shall increment the semzcnt associated with the specified semaphore and suspend execution of the calling thread (block) until one of the following occurs: - The value of semval changes. When this occurs, the value of semzcnt associated with the specified semaphore shall be decremented and the array of semaphore operations shall be reevaluated. - The semid for which the calling thread is awaiting action is removed from the system. When this occurs, the operation shall fail with errno set to [EIDRM]. - The calling thread receives a signal that is to be caught. When this occurs, the value of semzcnt associated with the specified semaphore shall be decremented, and the calling thread shall resume execution in the manner prescribed in sigaction(). Upon successful completion of all of the semaphore operations specified in the array pointed to by sops the value of sempid for each semaphore specified in the array shall be set to the process ID of the calling process and the sem_otime timestamp associated with the semaphore set shall be set to the current time, as described in Section 2.7.1 (on page xxx). 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 (circulated to Austin Core). We left open pending Mark. 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 0000630: Sentence is missing "for finite x" Accepted As Marked http://austingroupbugs.net/view.php?id=630 This item has been tagged for TC2-2008. Here are the proposed actions: On P696 L23586 delete: For IEEE Std 754-1985 double, 710.5 < |x| implies that cosh(x) has overflowed. On P767 L25598 delete: Note for IEEE Std 754-1985 double, 26.55 < x implies erfc(x) has underflowed. On P787 L26297 delete: Note that for IEEE Std 754-1985 double, 709.8 < x implies exp(x) has overflowed. The value x< -708.4 implies exp(x) has underflowed. On P789 L26366 delete: For IEEE Std 754-1985 double, 1024 <= x implies exp2(x) has overflowed. The value x< -1022 implies exp(x) has underflowed. On P791 L26426 delete: For IEEE Std 754-1985 double, 709.8 < x implies expm1(x) has overflowed. On P2106 L66639 delete: For IEEE Std 754-1985 double, overflow happens when 0 < x < 1/DBL_MAX, and 171.7 < x. Bug 0000625: Allowing alarm-based sleep() implementation contradicts requirement of thread-safety OPEN http://austingroupbugs.net/view.php?id=625 We noted that the description of SIGEV_THREAD notification in XSH 2.4.2 says "Multi-threaded programs can use ..." This suggests an approach involving adding definitions of multi-threaded program and single-threaded program. We should also define multi-threaded process and single-threaded process to emphasise the distinction. Below is a first attempt at the definitions, plus a definition of multi-threaded library, as that is used in one of the others: 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. Next Steps ---------- The next call is on December 20 (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