From rinehuls@access.digex.net Thu Oct 9 18:28:10 1997 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA08226 for ; Thu, 9 Oct 1997 18:27:11 +0100 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.8.4/8.8.4) with SMTP id NAA08194 for ; Thu, 9 Oct 1997 13:27:02 -0400 (EDT) Date: Thu, 9 Oct 1997 13:27:01 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2594 - Record of Responses for Defect Reports re Amendment 2 to 9945-1 - POSIX C Binding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII _____________ beginning of title page ________________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2594 TITLE: WG15 Record of Responses for Defect Reports 1 through 32 for Amendment 2 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX) - POSIX C Binding And Letter Ballot DATE ASSIGNED: 1997-10-07 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Record of Responses for Defect Reports PROJECT NUMBER JTC 1.22.21.04.01 STATUS: In accordance with SC22 N1236, non-responses to the letter ballot will be considered as agreement with the proposed record of responses. Note that Amendment 2 was incorporated into ISO/IEC 9945-1 when it was revised in 1996. ACTION IDENTIFIER: ACT DUE DATE: 1998-02-09 DISTRIBUTION: Text CROSS REFERENCE: N/A DISTRIBUTION FORM: Open Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ____________________end of title page; beginning of letter ballot _____ ---------------------------------------------------------------------- Attachment to JTC 1/SC22 N2594 Circulation Date: 10-24-97 LETTER BALLOT FROM THE MEMBER BODY OF ___________________________________________ On WG15 Record of Responses for Defect Reports 01 through 32 for Amendment 2 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX) - POSIX C Binding This letter ballot is to be returned by each "P" Member Body to the Secretariat of JTC 1/SC22 by FEBRUARY 9, 1998. ------------------------------------------------------------------------- _____ We agree with the Record of Responses or _____ We agree with the Record of Responses with the attached comments or _____ We do not agree with the Record of Responses for the technical reasons attached to this ballot. or _____ We abstain from voting. ("P" MEMBER BODIES HAVE AN OBLIGATION TO VOTE.) * CHECK WHICHEVER APPLIES. Name (please print) _______________________ Signature (if mailed) _____________________ Date: _________ ------------------------------------------------------------------------- ______ end of letter ballot; beginning of document _____________________ WG15 Record of Responses for Defect Reports 1 through 32 for Amendment 2 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX), POSIX C Binding Below find 24 Records of Response for interpretations/defects as reported by the U.S. to WG15. They are numbered with the Standard (IS 9945-1Amd2), followed by a tracking number used in the U.S. This is proposed to SC22 as a Record of Responses for approval by SC22 for the defects/interpretations indicated in the text. The specific Defect Reports included are 1 through 4, 6 through 16, 18 through 22, 24, 27, 28 and 32. The missing numbers reference reports that did not require a record of response (withdrawn, technical corregenda), or which have not yet resulting in an accepted response. ISO/IEC 9945-1-amd2 Interpretations Log ------------------------------------------------------------------------ 9945-1-amd2-01 Topic: Get User Name Relevant Sections: 4.2.4, 4.7.2 9945-1-amd2-02 Topic: pthread_key_delete Relevant Sections: 2.8.4, 17.1.1.4, 17.1.3 9945-1-amd2-03 Topic: Miscellaneous Relevant Sections: Many 9945-1-amd2-04 Topic: pthread_atfork - Headers and Functions Relevant Sections: 3.1.3.1 lines 79-81 , 2.7.3 9945-1-amd2-06 Topic: 6.7.1.1 Relevant Sections: _POSIX_PRIORITIZED_IO 9945-1-amd2-07 Topic: PTHREAD_INHERIT_SCHED Relevant Sections: ?? 9945-1-amd2-08 Topic: pthread_key_create() Relevant Sections: 17.1.1.2 9945-1-amd2-09 Topic: pthread_atfork() Relevant Sections: 3.1.3.1 9945-1-amd2-10 Topic: cancellation points Relevant Sections: 18.1.2 9945-1-amd2-11 Topic: sigpending() Relevant Sections: 3.3.6.2 9945-1-amd2-12 Topic: thread specific data Relevant Sections: 3.1.3.2 9945-1-amd2-13 Topic: sigevent structure Relevant Sections: 6.7.1.1 (POSIX 9945-1-amd1-93) 9945-1-amd2-14 Topic: stacksize Relevant Sections: 16.1.1.2 9945-1-amd2-15 Topic: default value for attribute Relevant Sections: 13.5.1.2 9945-1-amd2-16 Topic: sigpending Relevant Sections: 3.3.6.2 9945-1-amd2-18 Topic: stackaddr attribute Relevant Sections: 16.1.1.2 9945-1-amd2-19 Topic: sched_setparam Relevant Sections: 13.3.3.2 9945-1-amd2-20 Topic: protocol attribute etc Relevant Sections: 13.6.1.2 9945-1-amd2-21 Topic: timers and SIGEV_THREAD Relevant Sections: 14.2.2.2 (9945-1-amd1) 9945-1-amd2-22 Topic: pthread_setspecific Relevant Sections: 17.1.2.2 9945-1-amd2-24 Topic: schedpolicy etc Relevant Sections: 13.5.1.2 9945-1-amd2-27 Topic: pthread_mutexattr_init Errors Relevant Sections: 11.3.1.4 9945-1-amd2-28 Topic: Waiting on a Condition Errors Relevant Sections: 11.4.4.4 9945-1-amd2-32 Topic: Thread-Specific Data Key Creation Description Relevant Sections: 17.1.1.2 ------------------------------------------------------------------------ WG15 Defect Report Ref: 9945-1-amd2-01 Topic: Get User Name 9945-1-amd2-95 #1 Defect Report Number: XXXX Topic: Get User Name Relevant Sections: 4.2.4, 4.7.2 Defect Report: ----------------------- I am referring to sections 4.2.4 (Get User Name) and 4.7.2 (Determine Terminal Device Name). POSIX.1c is ambiguous when getlogin_r() and ttyname_r() cannot find the login or tty name, requiring that an error code is to be returned but not identifying a specific error code. Since the standard fails to specify a return code, applications cannot expect to portably handle this condition. Is this an oversight in the specification? I suggest that ESRCH should be the error returned these functions cannot find a name. 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. The standard is silent on what err shall be returned and the interpretations committee belives that the silence is intentional. Strictly conforming implementations are not constrainted in what they may return and applications shall be ready to deal with varying behaviors. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-02 Topic: pthread_key_delete 9945-1-amd2-95 #2 Defect Report Number: XXXX Topic: pthread_key_delete Relevant Sections: 2.8.4, 17.1.1.4, 17.1.3 Defect Report: ----------------------- This is a request for interpretation on an issue in the forthcoming POSIX 9945-1-amd2, presumably 1996. Right now all I have to work from are the draft 8, 9, and 10 documents, but draft 10 was approved as the final specification. My question involves sections 2.8.4, 17.1.1.4, and 17.1.3 Briefly, may/must pthread_key_delete make the key value available for re-use? Section 2.8.4 defines PTHREAD_KEYS_MAX as being the number of data keys that can created per process. 17.1.1.4 says that pthread_key_create shall return EAGAIN if "the system-imposed limit on the total number of keys per process {PTHREAD_KEYS_MAX} has been exceeded." 17.1.3.2 the rationale for pthread_key_delete, says "A thread-specific data key deletion function has been included in order to allow the resources associated with an unused thread-specific data key to be freed." Consider the following example. Assume that this application does nothing else with any thread-specific data. pthread_key_t keys[PTHREAD_KEYS_MAX], key_A, key_B; int i, status_A, status_B; struct foobar data[PTHREAD_KEYS_MAX]; for (i = 0; i < PTHREAD_KEYS_MAX; i++) { /* these calls all succeed */ (void) pthread_key_create (&(keys[i]), NULL); pthread_setspecific (keys[i], (void *) &(data[i])); } pthread_key_delete(keys[5]); /* this should succeed */ status_A = pthread_key_create (&key_A, NULL); /* Unclear about this */ pthread_setspecific (keys[6], (void *) NULL); /* this should succeed */ pthread_key_delete(keys[6]); /* this should succeed */ status_B = pthread_key_create (&key_B, NULL); /* Unclear about this */ Questions: 1) May status_A be 0? (I recommend "yes") 1.1) If so, may key_A equal keys[5]? (I recommend "yes") 2) Must status_A be 0? (I recommend "no") 3) May status_A be EAGAIN? (I recommend "yes") 4) Must status_A be EAGAIN? (I recommend "no") 5) May status_B be 0? (I recommend "yes") 5.1) If so, may key_B equal keys[6]? (I recommend "yes") 6) Must status_B be 0? (I recommend "no") 7) May status_A be EAGAIN? (I recommend "yes") 8) Must status_A be EAGAIN? (I recommend "no") I expect that the answers to questions 1-4 will be identical to the answers to 5-8, but I wanted to point out the distinction of having a non-NULL thread-specific data value at the time of the pthread_key_delete call. The answers I have recommended above coincide with my reading of the normative text of the standard, but the wording in the 17.1.3.2 rationale for pthread_key_delete leaves me uneasy. While I have your attention, I'll add another question that is somewhat redundant with the above. 9) In 2.8.4, should the definition for PTHREAD_KEYS_MAX, which reads "Maximum number of data keys that can be created per process", be interpreted to not include in the count those data keys that have been deleted? If so, I would suggest changing the definition to "Maximum number of data keys that can exist per process". Interpretation response ------------------------ The standard states that once the system defined limit: PTHREADS_KEYS_MAX keys have been created, the call shall return the indicated error and conforming implementations must conform to this. However, concerns have been raised about this behavior which are being forwarded to the sponsor. In the view of the interpretations committee, this is not what the balloting group intended. The provision of a Delete function and the rationale for this function make the intent very clear that keys should be reusable with a limit on the number of "simultaneous" keys. The wording in the definition should possibly have been similar to POSIX_OPEN_MAX or POSIX_CHILD_MAX. This matter is being refered to the sponsor for consideration as a technical correction. Additionally, the interpretation committee noted that PTHREADS_THREADS_MAX may have a similar problem and have refered this to the sponsor as well. Specific answers: 1. -> No 2. -> No 3. -> Yes, must be EAGIN 4. -> Yes, 5. -> No 6. -> No 7./8. same as 3/4" Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-03 Topic: Miscellaneous 9945-1-amd2-95 #3 Topic: Miscellaneous Relevant Sections: Many Defect Report: ----------------------- 1) Section 16.1.1.2, page 141 D10, lines 79-83 A default value for the stackaddr attribute is not specified. The bahvior is specified if an application wants to specify their own stack. It does not specify what to do if they want to implementation to create a stack for them. What is the default value of this attribute? NULL to signify the user wants the implementation to allocate stacks? 2) Section 16.1.1.2, page 141 D10, lines 74-78 A default value of the stacksize attribute is not specified. The behavior is specified if an application wants to specify their own stack size. It does not specify the value of stacksize if the user wants the implementation to use a default stacksize. What is the correct stacksize to return as a default value when the user has not specified a stacksize? Some implementations specify a default value of 0 for a default stack. Other implementations specify a default value of PTHREAD_STACK_MIN. This confusion can lead to source code portablity problems. 3) Section 13.5.1.2, page 121 D10, lines 316-332 A default value for the inheritsched attribute is not specified. The default behavior needs to be specified for portable applications or it could result in differing behavior across platforms. What is the default value for inheritsched? 4) Section 13.5.1.2, page 122 D10, lines 333-342 A default value for the schedpolicy attribute is not specified. What is the default value for this attribute? 5) Section 13.5.1.2, page 122 D10, lines 353-357 A default value for the schedparam attribute is not specified. What is the default value for this attribute? Implementations are already providing different values (drastically) which will effect portability. Some implementations consider the default value to be NULL, others return an actual value for this attribute as the default value. This case is not merely different default values, but actual differences in what this attribute represents. This impacts portability. What is the default value/behavior of this attribute? 6) Section 17.1.2.2, page 166 D10, lines 192-195 This paragraph states that calling pthread_setspecific() from within a destructor function may result in lost storage or infinite loops. This can be a real problem. POSIX.1c has just stated that it is impossible to use thread-specific data in an application. A portable and correctly behaving application cannot rely on calling pthread_setspecific() from within a destructor function. What makes thread-specific data impossible to use is the fact that in pthread_key_create() it is stated that when a thread terminates, any non-NULL TSD values which have destructors will have the destructor called for them. The problem here is that the destructor function is called in a loop (potentially forever - so a portable application has to assume forever) until the key value is NULL. However, according to pthread_setspecifc() a portable and correctly behaving application has no way possible to change the key value to a NULL value. Portable application have to rely on "worst case" guaranteed behavior. According to the definitions of pthread_setspecific() and pthread_key_create() an application cannot reliably make use of thread-specific data with destructor functions or its thread will end up in an infinite loop. Could you please clarify the intended behavior of these functions? Obviously there must be something missing here or this looping behavior for destructor functions would not have been added since an application must assume it results in an infinite loop. 7) Section 13.3.1.2, page 114 D10, lines 30-36 Section 13.3.3.2, page 114 D10, lines 42-48 According to the new rules for scheduling, the sched_setparam() and sched_setscheduler() are not useless in the presence of multithreaded applications. The only effect these functions have is on the child process (from fork()) of the target process. An implementation may cause something to happen to the process scope threads, but thats all. This provides a huge hole for system administrators. These functions have a process d parameter. This means they were intended so that a process could control the policy and priority of another process. If that wasn't the case, there wouldn't have been a pid as a parameter. Up until now a system administrator could control a process if it was getting too much or too little time on the system. Runaway processes with high priority could be habndled. With the new behavior, there is no way a sysadmin (or any process) can control the behavior of a multithreaded process. If some event happens requiring a change in the policy/priority of the MT process, only the process itself can do it. The worst part is that if one thread in the process goes out of control while high prio SCHED_FIFO, no one can control it. A sysadmin cannot do anything to lower that thread's priority (thread IDs are not guaranteed to be known outside of the system). Is this the actual intended behavior????? 8) Section 13.6.1.2, page 128-129 D10, lines 581-587 What is the default value of the protocol attribute? 9) Section 13.6.1.2, page 128-129 D10, lines 578-580, 595-606 PTHREAD_PRIO_PROTECT This states that a) the priority of the locking thread shall raise its priority to the mutex prioceiling and b) that prioceiling must be a valid priority for SCHED_FIFO. What happens if the locking thread is not SCHED_FIFO? Chances are pretty good that the prioceiling value is not a valid priority for the scheduling policy of the thread. Even if the thread is SCHED_RR the value may not be valid. Do these functons imply that you must also change the scheduling policy of the locking thread to SCHED_FIFO? If so, what happens if the system defines SCHED_FIFO to have lower priorities than say SCHED_RR and the thread is under SCHED_RR? 10) Section 13.6.1.2, page 128-129 D10, lines 590-594 PTHREAD_PRIO_INHERIT This states that the blocking thread shall raise the priority of the thread owning the mutex to equal that of the blocking thread. Only the priority is being changed here. What happens if the threads are in different scheduling policies? The new priority may not be valid in that scheduling policy. Is it assumed that these functions also change the policy of the thread if they are different? 11) Section 3.1.3.2, page 27 D10, lines 84-94 This function allows an application to essentially install cancellation type handlers to guarantee that the proper state is maintained in the child process after a fork. What is supposed to happen with allocated thread-secific data in the child process? These functions are, in effect, executed by the thread calling fork. If the other threads have allocated a lot of thread-specific data, there is no way for the process to release that memory. The child has immediately inherited a memory leak when using TSD. Is this intended? 12) Section 3.3.6.2, page 39 D10, lines 492-494 This section states that sigpending() returns the signals pending on "either" the process or the thread. The way stated, an implementation is allowed to return process pending signals or thread pending signals. An application cannot portably use and rely on what this function does because of "either". What the actual intent to say something more like "returns the union of the signals pending on the process and the calling thread"? 13) Section --> None in 9945-1-amd2 D10, corresponding section in 9945-1-amd1 is Section 14.2.2.2 The behavior for timer_create() specifies what happens when a sigevent structure of type SIGEV_NONE or type SIGEV_SIGNAL is passed to the function. POSIX.1c does not specify what the behavior of this function is if the sigevent structure is for SIGEV_THREAD. The most complicated part is when sigevent specifies SIGEV_THREAD but the timer is a reloading timer so that it continually expires. What is supposed to happen with timers and SIGEV_THREAD? A thread is to be created when the timer expires? What happens with reloading timers which continually expire? Does only one thread get created and from then on an overrun count is incremented? Since these threads are detached, you have no way of knowing this thread terminates in order to stop incrememnting the count and create a new thread on the next timer expiration. Interpretation response ------------------------ 1. Stack address: The standard is clear that the default value of the stackaddr attribute is "unspecified". A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. If the attribute is supported, the application can specify the placement of the stack by using an attribute object for thread creation and the function pthread_attr_setsetstacksize. The interpretations committee believes that this was the intent of the working and balloting groups. Due to the complexities of O/S and compiler interactions, the expectation was that the thread implementation will wish to reserve to itself the ability to determine the placement and size of the stack. The rationale for adding the functions to set the fields was derived from the needs of real-time systems and embedded environments where the management of memory is often handled by the application writer. An application writer wishing to force a particular stack address will need to be vary cautious since different systems, processors, O/Ss, and compilers will varying in the amount of memory required for the stack of an application. This issue is analogous to the stack creation in the exec functions, where there are no particular requirements on the location or size of the stack in the new process image. 2. Stack size: The standard is clear that the default value of the stacksize attribute is "unspecified". A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. If the attribute is supported, the application can specify the value of the stack size by using an attribute object for thread creation and the function pthread_attr_setsetstacksize. The interpretations committee believes that this was the intent of the working and balloting groups. Due to the complexities of O/S and compiler interactions, the expectation was that the thread implementation will wish to reserve to itself the ability to determine the placement and size of the stack. The rationale for adding the functions to set the fields was derived from the needs of real-time systems and embedded environments where the management of memory is often handled by the application writer. An application writer wishing to force a particular stack size will need to be vary cautious since different systems, processors, O/Ss, and compilers will varying in the amount of memory required for the stack of an application. This issue is analogous to the stack creation in the exec functions, where there are no particular requirements on the location or size of the stack in the new process image. 3. Inheritsched The standard is clear that the default value of the inheritsched attribute is "unspecified". A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. The application can specify the value of inheritsched by setting it in the attribute object using the function pthread_attr_setinheritsched. The interpretations committee believes that this was the intent of the working and balloting groups. Due to the wide variety and uses of O/Ss implementing the standard, the expectation is that the implementation will have a default that makes sense in its context. 4. schedpolicy The standard is clear that the default value of the schedpolicy attribute is "unspecified". A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. The application can specify the value of the schedpolicy by setting it in the attribute object using the function pthread_attr_setschedpolicy. The interpretations committee believes that this was the intent of the working and balloting groups. Due to the wide variety and uses of O/Ss implementing the standard, the expectation is that the implementation will have a default that makes sense in its context. 5. schedparms The standard is clear that the default value of the schedparms attribute is unspecified. A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. The application can specify the value of schedparms by setting it in the attribute object using the function tthread_attr_setschedparm. The interpretations committee believes that this was the intent of the working and balloting groups. Due to the wide variety and uses of O/Ss implementing the standard, the expectation is that the implementation will have a default that makes sense in its context. 6. pthread_setspecific The standard is clear in defining the circumstances under which lost storage of infinite loops may occur as a result of using thread specific data. The statement in section 17.1.2.2, lines 72-74 that "calling pthread_setspecific() from a destructor may result in lost storage or infinite loops" is clarified by the description of destructor behavior in section 17.1.1.2, lines 26-33. In particular, the circumstances under which an infinite loop or lost storage might occur are described, those being when {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls have been made and non-NULL key values remain. As such, calling pthread_setspecific() specifying a NULL value is always safe (even in destructors) since it will not result in such storage loss or infinite loops. Interpretation request number 8 raised a related issue -- asking under what circumstances a thread-specific data value is set to NULL during destructor calls. The standard currently only describes one way -- an explicit call to pthread_setspecific(key, NULL). The interpretations committee believes that it was the intent of the working and balloting groups that the thread-specific data value associated with a key should automatically set to NULL before the destructor is called in order to prevent infinite loops. Otherwise each destructor function would have to somehow determine the key for which it was invoked and do a pthread_setspecific(key, NULL) in order to prevent infinite loops. 7. Can't set thread scheduling parameters from another process The standard is clear that it does not define any interfaces to provide this function. The interpretations committee believes that this was the intent of the working and balloting groups in order to allow the widest possible types of implementations and, specifically, library level implementations would not be able to expose such a system call to another process. 8. protocol The standard is clear that the default value of the protocol attribute is "unspecified". A conforming system is free to choose any value for this field and a conforming application must correctly handle any value. The application can specify the value of the protocol by setting it in the attribute object using the function pthread_mutexattr_setprotocol and then using the attribute object for the creation of a mutex. The interpretations committee believes that this was the intent of the working and balloting groups. 9. PTHREAD_PRIO_PROTECT The standard is clear on pages 305-6 lines 701-705 that the process executes at the higher of its priority or that of prioceiling. On pages 287-8, the model of scheduling is clear that, conceptually, there is an ordering for all possible priority values, independent of scheduling policy. In the case that the effective priority range of Sched-RR is higher than that of Sched-FIFO, then the mechanisms provided to guard against priority inversion would likely be unsuccessful, should any Sched_RR threads use the mutex. The interpretations committee believes that this was the intent of the working and balloting groups. Note also that the standard does not require that the priority_ceiling value be a valid priority level for the class of a locking thread. A thread's priority is not affected by its inheritance, only its execution. See also interpretation #10. 10. PTHREAD_PRIO_INHERIT The standard is clear on pages 287-8 that the specification of a scheduling policy is in the context of a conceptual model that requires specifying the relationship between the different polices. The system is to execute the thread with the highest effective priority independent of scheduling policy. To achieve this, it may be necessary for a thread's effective priority to be set to a value outside its policy's priority range. 11. Fork Handlers The standard is clear that memory allocated as thread-specific data for threads other than the forking thread might be leaked in the child process if not freed or otherwise accounted for at fork time since only a copy of the thread that called fork() will exist in the child process. This is the intended behavior. Three mechanisms that applications can use to eliminate this leakage are described in the rationale in section B.3.1.3. (1) Perform an exec() call. (2) Use the pthread_atfork() prepare handler to clean up any state associated with other threads before the fork() is executed. (3) Use the pthread_atfork() child handler to clean up any state associated with other threads after the fork() is executed. 12. Signal value returned by sigpending() The standard is clear that the set of signals returned by sigpending() consists of all of those signals that are blocked from delivery and are pending on either the process or the calling thread. Equivalently, this is the union of the following two sets of signals: 1. The set of signals that are blocked from delivery and pending on the process. 2. The set of signals that are blocked from delivery and pending on the calling thread. 13. SIGEV_THREAD The standard is clear on page 74 lines 696-698 that each execution of the signal handler shall be executed in an environment as if it were the start routine of a new thread. The interpretations committee notes that the language in subclause 14.2.2.2 specifying the notification semantics for timer expiration was changed by 9945-1i to explicitly refer to 3.3.1.2. It is unspecified as to whether multiple signals would be executed sequentially or in parallel: conforming systems are free to do either and conforming applications shall handle the case of parallel execution. The interpretation committee believes that this was the intent of the working and balloting groups in order to allow a wide range of implementations. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-04 Topic: pthread_atfork - Headers and Functions 9945-1-amd2-95 #4 Topic: pthread_atfork - Headers and Functions Relevant Sections: 3.1.3.1 lines 79-81 , 2.7.3 Defect Report: ----------------------- Which header is the function pthread_atfork() defined in? Should it be pthread.h. At the moment this has been ommitted from that header. Was this intentional? Interpretation response ------------------------ The 9945-1-amd1 standard, to which 9945-1-amd2 is an amendment, on page 39 section 2.7.3 lines 1119 to 1121, states that "if a function is not listed below, it shall have its prototype appear in ..". pthread_atfork is not listed, so the standard is clear that it shall be listed in . Rationale ------------- None WG15 Defect Report Ref: 9945-1-amd2-06 Topic: 6.7.1.1 9945-1-amd2-95 #6 Topic: 6.7.1.1 Relevant Sections: _POSIX_PRIORITIZED_IO Defect Report: ----------------------- FOR ISO/IEC 9945-1-amd2-1995: 1c1. Subsection 6.7.1.1: The first sentence of the fifth paragraph of section 6.7.1.1 says "If {_POSIX_PRIORITIZED_IO} and {_POSIX_PRIORITY_SCHEDULING} are defined, then asynchronous I/O is queued in priority order, with the priority of each asynchronous operation based on the current scheduling priority of the calling process." The statement is ambiguous when the calling process is multi-threaded. If a multi-threaded process initiates async I/O requests from threads of various priorities, what is the "priority of the requesting process" for each such request - the priority of the requesting thread, or something else? This is ill-defined, as a multi-threaded process may have several priorities. Assuming that the interpretation answers "the priority of the requesting thread" to the above question, I suggest that the word "process" in the sentence be changed to "thread". Another possibility is that it is the priority of the "initial" thread started when the process was created, but this creates problems for async I/O requests from other threads subsequently created with a higher priority, since they cannot utilize their higher priority to advantage. Interpretation response ------------------------ The standard is clear: the priority is that of the process as set by sched_setparam or other mechanisms. Even in the presence of threads this remains a 'well defined' term and value. A conforming implementation shall use that value in the calculation of the I/O priority. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-07 Topic: PTHREAD_INHERIT_SCHED 9945-1-amd2-95 #7 Topic: PTHREAD_INHERIT_SCHED Relevant Sections: ?? Defect Report: ----------------------- This is a request for interpretation on an issue in the forthcoming POSIX 9945-1-amd2, presumably 1996. Right now all I have to work from are the draft 8 document, plus the draft 9 and 10 change documents, but draft 10 was approved as the final specification. My question concerns section 13.5.1.1 in draft 8 (lines 302-306) This text was not modified by the drafts 9 or 10 changes documents. When a thread is created with a value of PTHREAD_INHERIT_SCHED for the inheritsched attribute, is the scheduling contention scope one of the atributes that is inherited? Or should the new thread get the implementation-defined default scheduling contention scope? Interpretation response ------------------------ The standard is clear: contentionscope is one of the attributes controlled by inheritsched. 9945-1-amd2 page 296 line 397 states: "The contentionscope attribute defines the scheduling ...." and on line 401 the standard uses this fact ".....set according to the other scheduling attributes in pthread_attr_t object." Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-08 Topic: pthread_key_create() 9945-1-amd2-95 #8 Topic: pthread_key_create() Relevant Sections: 17.1.1.2 Defect Report: ----------------------- There seems to be an editorial error in POSIX 9945-1-amd2 regarding pthread_key_create() The pthread_key_create section 17.1.1.2 of 9945-1-amd2 is very unclear. As written today it easily leads one to believe that it is required that the destructor function be called until the thread-specific value becomes NULL, or until PTHREAD_DESTRUCTOR_ITERATIONS iterations have occured, which ever comes first. If you read the draft POSIX 9945-1-amd2 standard revisions, it's clear what the intent was. Between draft standards a sentance was lost which said "Before each destructor is called, the thread's value for the corresponding key is set to NULL". The re-iteration exists so that if the destructor uses keys, they will be destroyed in a re-call to the destructor. Was this omission an editorial error? Interpretation response ------------------------ The standard states that the destructor is called with the current associated value as its only argument and it is repeatedly called until PTHREAD_DESTRUCTOR_ITERATIONS or the value associated with the key becomes null. Conforming implementations must conform to this. However, concerns have been raised that the intent of the working and balloting groups was somewhat different and that the associated value should automatically set to NULL before the destructor is called in order to prevent infinite loops. This is needed since the destructor function does not have a way to determine which key that caused it to be invoked and thus does not have a way to null the value. The committee feels that this is a problem and it is being refering it to the sponsor for consideration. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-09 Topic: pthread_atfork() 9945-1-amd2-95 #9 Topic: pthread_atfork() Relevant Sections: 3.1.3.1 From: Andrew Josey Date: Wed Jul 10 15:50:23 BST 1996 Defect Report: ----------------------- This is related to Interpretation reference 9945-1-amd2 #04 and the inter-relation between 9945-1-amd2 and 9945-2. Interpretation 9945-1-amd2-95 #04 stated: The 9945-1-amd1 standard, to which 9945-1-amd2 is an amendment, on page 39 section 2.7.3 lines 1119 to 1121, states that "if a function is not listed below, it shall have its prototype appear in ..". pthread_atfork is not listed, so the standard is clear that it shall be listed in . 9945-2 states that the functions in are made available, when -l c is the argument to c89: POSIX.2 lines 167-169 page 691 states " -l c This library contains all library functions referenced in , , , , , ...". Is it thus the correct interpretation for 9945-1-amd2 that the pthread_atfork() function be in the standard library found with the -l c argument? I'd propose that this be in a libary other than that named found by "-l c". Interpretation response ------------------------ The response of the 9945-1-amd2 Interpretations committee is: The standard is clear that pthread_atfork() is made available by the -l c argument to c89. As stated in interpretation 9945-1-amd2 #4: The 9945-1-amd1 standard, to which 9945-1-amd2 is an amendment, on page 39 section 2.7.3 lines 1119 to 1121, states that "if a function is not listed below, it shall have its prototype appear in .". pthread_atfork is not listed, so the standard is clear that it shall be listed in . and 9945-2 says: the functions in are made available when -l c is the argument to c89. However, it is the belief of the interpretations committee that this is not what was intended by the working group or the balloting group. The rationale in informative annex C, page 593, line 183, lists pthread_atfork() as being defined in . Additionally, the "pthread_" function is the only one made available by the -l c argument to c89 is pthread_atfork(), which does not give the user of the standard a useful set of functions. This issue is being referred to the sponsor for consideration. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-10 Topic: cancellation points 9945-1-amd2-95 #10 Topic: cancellation points Relevant Sections: 18.1.2 Defect Report: ----------------------- Section 18.1.2 has the wording: "A cancellation point may also occur when a thread is executing the following functions" This is incorrect and doesn't explain the intent of this section. According to the current wording, an implementation is not required to support cancellation. The definition of "may" according to this document is "..., the feature or behavior is optional." This means that an implementation is allowed to disable cancelability within these functions. The actual intent of POSIX is to say that these functions are cancellation points if they happen to block during the course of the function call. For all functions listed, sometimes they may block, sometimes they may not. The wording as stated is incorrect and allows for incorrectly coded implementations. An interpretation is requested to clarify the intended behavior of these interfaces with respect to cancellation. We believe the following change is the intent. Change the wording: "A cancellation point may also occur when a thread is executing the following functions:" To: "A cancellation point will also occur in the following functions if the function causes the thread to block:" Interpretation response ------------------------ The "intent" is that the functions listed in ISO 9945-1:1996 following line 56 in 18.1.2 are allowed to be cancellation points, just in case they are implemented using other routines specified to be cancellation points. Were it not for this language, these routines cannot use routines which are cancellation points in their implementation because the standard says that no POSIX/ISO C routines other than those specified are cancellation points. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-11 Topic: sigpending() 9945-1-amd2-11 Topic: sigpending() Relevant Sections: 3.3.6.2 Defect Report: ----------------------- Section 3.3.6.2 states "are pending either for the process or the calling thread". The present wording text allows for implementations that differ severely and impacts application portability. This should be better restated as "the union of signals pending for the process and calling thread". The intent is to return the set of signals which are pending and may be processed by the calling thread, whether pending on the thread or the process (ie, the union of the process and thread pending signals). By saying "either the process or the calling thread", an implementation is allowed to return one or the other. If system A returns pending signals for the calling thread, and system B returns pending signals for the process, applications will not be portable. This needs clarification. We believe the wording could be better phrased as "the union of signals pending for the process and calling thread which are blocked from delivery for the calling thread" Interpretation response ------------------------ This is a duplicate of ISO/IEC 9945-1-amd2 Interpretation Request #3 subquestion 12 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-12 Topic: thread specific data 9945-1-amd2-95 #12 Topic: thread specific data Relevant Sections: 3.1.3.2 Defect Report: ----------------------- Section 3.1.3.2, page 27 D10, lines 84-94 This function allows an application to essentially install cancellation type handlers to guarantee that the proper state is maintained in the child process after a fork. What is supposed to happen with allocated thread-secific data in the child process? These functions are, in effect, executed by the thread calling fork. If the other threads have allocated a lot of thread-specific data, there is no way for the process to release that memory. The child has immediately inherited a memory leak when using TSD. Is this intended? There is no way of using pthread_atfork() to release other threads' thread specific data. Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 11 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-13 Topic: sigevent structure 9945-1-amd2-95 #13 Topic: sigevent structure Relevant Sections: 6.7.1.1 (POSIX 9945-1-amd1-93) Defect Report: ----------------------- Section --> None in 9945-1-amd2 D10, corresponding section in 9945-1-amd1 is: Section 6.7.1.1 The behavior is specified when a sigevent structure of type SIGEV_NONE or type SIGEV_SIGNAL is passed. POSIX.1c does not specify what the behavior is if the sigevent structure specifies SIGEV_THREAD. The behavior needs to be specified. According to the current definitions, these functions are not required to support SIGEV_THREAD, even if POSIX_THREADS is defined. They define SIGEV_SIGNAL AND SIGEV_NONE, but not SIGEV_THREAD. Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 13 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-14 Topic: stacksize 9945-1-amd2-95 #14 Topic: stacksize Relevant Sections: 16.1.1.2 Defect Report: ----------------------- Section 16.1.1.2, page 141 D10, lines 74-78 A default value of the stacksize attribute is not specified. The behavior is specified if an application wants to specify their own stack size. It does not specify the value of stacksize if the user wants the implementation to use a default stacksize. What is the correct stacksize to return as a default value when the user has not specified a stacksize? Some implementations specify a default value of 0 for a default stack. Other implementations specify a default value of PTHREAD_STACK_MIN. This confusion can lead to source code portablity problems. Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 2. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-15 Topic: default value for attribute 9945-1-amd2-95 #15 Topic: default value for attribute Relevant Sections: 13.5.1.2 Defect Report: ----------------------- Section 13.5.1.2, page 121 D10, lines 316-332 A default value for the inheritched attribute is not specified. The default behavior needs to be specified for portable applications or it could result in differing behavior across platforms. What is the default value for inheritched? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 3 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-16 Topic: sigpending 9945-1-amd2 #16 Topic: sigpending Relevant Sections: 3.3.6.2 Defect Report: ---------------------- Section 3.3.6.2, page 39 D10, lines 492-494 This section states that sigpending() returns the signals pending on "either" the process or the thread. The way stated, an implementation is allowed to return process pending signals or thread pending signals. An application cannot portably use and rely on what this function does because of "either". What the actual intent to say something more like "returns the union of the signals pending on the process and the calling thread"? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 12 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-18 Topic: stackaddr attribute 9945-1-amd2-95 #18 Topic: stackaddr attribute Relevant Sections: 16.1.1.2 Defect Report: -------------------- Section 16.1.1.2, page 141 D10, lines 79-83 A default value for the stackaddr attribute is not specified. The bahvior is specified if an application wants to specify their own stack. It does not specify what to do if they want to implementation to create a stack for them. Additionally, since a default value is not specified AND it is not specified that by default the implementation allocates a stack, the programmer must always check the default value of this attribute before creating a thread. What is the default value of this attribute? NULL to signify the user wants the implementation to allocate stacks? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 1. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-19 Topic: sched_setparam 9945-1-amd2-95 #19 Topic: sched_setparam Relevant Sections: 13.3.3.2 Defect Report: ----------------------- Section 13.3.1.2, page 114 D10, lines 30-36 Section 13.3.3.2, page 114 D10, lines 42-48 According to the new rules for scheduling, the sched_setparam() and sched_setscheduler() are not useless in the presence of multithreaded applications. The only effect these functions have is on the child process (from fork()) of the target process. An implementation may cause something to happen to the process scope threads, but thats all. This provides a huge hole for system administrators. These functions have a process parameter. This means they were intended so that a process could control the policy and priority of another process. If that wasn't the case, there wouldn't have been a pid as a parameter. Up until now a system administrator could control a process if it was getting too much or too little time on the system. Runaway processes with high priority could be habndled. With the new behavior, there is no way a sysadmin (or any process) can control the behavior of a multithreaded process. If some event happens requiring a change in the policy/priority of the MT process, only the process itself can do it. The worst part is that if one thread in the process goes out of control while high prio SCHED_FIFO, no one can control it. A sysadmin cannot do anything to lower that thread's priority (thread IDs are not guaranteed to be known outside of the system). Is this the actual intended behavior? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 7 Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-20 Topic: protocol attribute etc 9945-1-amd2-95 #20 Topic: protocol attribute etc Relevant Sections: 13.6.1.2 Defect Report: ----------------------- 1) Section 13.6.1.2, page 128-129 D10, lines 581-587 What is the default value of the protocol attribute? 2) Section 13.6.1.2, page 128-129 D10, lines 578-580, 595-606 PTHREAD_PRIO_PROTECT This states that a) the priority of the locking thread shall raise its priority to the mutex prioceiling and b) that prioceiling must be a valid priority for SCHED_FIFO. What happens if the locking thread is not SCHED_FIFO? Chances are pretty good that the prioceiling value is not a valid priority for the scheduling policy of the thread. Even if the thread is SCHED_RR the value may not be valid. Do these functons imply that you must also change the scheduling policy of the locking thread to SCHED_FIFO? If so, what happens if the system defines SCHED_FIFO to have lower priorities than say SCHED_RR and the thread is under SCHED_RR? 3) Section 13.6.1.2, page 128-129 D10, lines 590-594 PTHREAD_PRIO_INHERIT This states that the blocking thread shall raise the priority of the thread owning the mutex to equal that of the blocking thread. Only the priority is being changed here. What happens if the threads are in different scheduling policies? The new priority may not be valid in that scheduling policy. Is it assumed that these functions also change the policy of the thread if they are different? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 8. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-21 Topic: timers and SIGEV_THREAD 9945-1-amd2-95 #21 Topic: timers and SIGEV_THREAD Relevant Sections: 14.2.2.2 (9945-1-amd1) Defect Report: ----------------------- Section --> None in 9945-1-amd2 D10, corresponding section in 9945-1-amd1 is Section 14.2.2.2 The behavior for timer_create() specifies what happens when a sigevent structure of type SIGEV_NONE or type SIGEV_SIGNAL is passed to the function. POSIX.1c does not specify what the behavior of this function is if the sigevent structure is for SIGEV_THREAD. The most complicated part is when sigevent specifies SIGEV_THREAD but the timer is a reloading timer so that it continually expires. What is supposed to happen with timers and SIGEV_THREAD? A thread is to be created when the timer expires? What happens with reloading timers which continually expire? Does only one thread get created and from then on an overrun count is incremented? Since these threads are detached, you have no way of knowing this thread terminates in order to stop incrememnting the count and create a new thread on the next timer expiration. Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 13. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-22 Topic: pthread_setspecific 9945-1-amd2-95 #22 Topic: pthread_setspecific Relevant Sections: 17.1.2.2 Defect Report: ----------------------- Section 17.1.2.2, page 166 D10, lines 192-195 This paragraph states that calling pthread_setspecific() from within a destructor function may result in lost storage or infinite loops. This can be a real problem. POSIX.1c has just stated that it is impossible to use thread-specific data in an application. A portable and correctly behaving application cannot rely on calling pthread_setspecific() from within a destructor function. What makes thread-specific data impossible to use is the fact that in pthread_key_create() it is stated that when a thread terminates, any non-NULL TSD values which have destructors will have the destructor called for them. The problem here is that the destructor function is called in a loop (potentially forever - so a portable application has to assume forever) until the key value is NULL. However, according to pthread_setspecifc() a portable and correctly behaving application has no way possible to change the key value to a NULL value. Portable application have to rely on "worst case" guaranteed behavior. According to the definitions of pthread_setspecific() and pthread_key_create() an application cannot reliably make use of thread-specific data with destructor functions or its thread will end up in an infinite loop. Could you please clarify the intended behavior of these functions? Obviously there must be something missing here or this looping behavior for destructor functions would not have been added since an application must assume it results in an infinite loop. Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 6. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-24 Topic: schedpolicy etc 9945-1-amd2-95 #24 Topic: schedpolicy etc Relevant Sections: 13.5.1.2 Defect Report: ----------------------- 1) Section 13.5.1.2, page 122 D10, lines 333-342 A default value for the schedpolicy attribute is not specified. What is the default value for this attribute? 2) Section 13.5.1.2, page 122 D10, lines 353-357 A default value for the schedparam attribute is not specified. What is the default value for this attribute? Implementations are already providing different values (drastically) which will effect portability. Some implementations consider the default value to be NULL, others return an actual value for this attribute as the default value. This case is not merely different default values, but actual differences in what this attribute represents. This impacts portability. What is the default value/behavior of this attribute? Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #3, part 5. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-27 Topic: pthread_mutexattr_init Errors 9945-1-amd2-95 #27 Topic: pthread_mutexattr_init Errors Relevant Sections: 11.3.1.4 Defect Report: ----------------------- 1. Section 11.3.1.4, pthread_mutexattr_init Errors pthread_attr_init and pthread_condattr_init both document ENOMEM as an "if occurs" error, but pthread_mutexattr_init documents ENOMEM as an "if detected" error. There is no reasonable justification for this difference, so clearly the specification of ENOMEM in the description of pthread_mutexattr_init was an oversight, and should be corrected. REF: page 254, section 11.3.1.4, line 472 page 260, section 11.4.1.4, line 685 page 335, section 16.2.1.4, line 95 Interpretation response ------------------------ The standards states that for the pthread_mutexattr_init() function ENOMEM is an "if detected" error and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor." Rationale ------------- This appears to be a defect. None. WG15 Defect Report Ref: 9945-1-amd2-28 Topic: Waiting on a Condition Errors 9945-1-amd2-95 #28 Topic: Waiting on a Condition Errors Relevant Sections: 11.4.4.4 Defect Report: ----------------------- 2. Section 11.4.4.4, Waiting on a Condition Errors All error conditions, except ETIMEDOUT for pthread_cond_timedwait, are reported by returning EINVAL. One of the error conditions in particular, "the mutex was not owned by the current thread at the time of the call" is an error that would be detected by unlocking the specified mutex prior to waiting. This same error is reported by pthread_mutex_unlock by returning the error EPERM. The standard should not report the same error in different places using different error codes. This error should be reported by returning EPERM for both pthread_cond_wait and pthread_cond_timedwait. REF: page 266, section 11.4.4.4, lines 898,899 page 258, section 11.3.3.4, line 615 Interpretation response ------------------------ The standard is clear that pthread_cond_timedwait should report EINVAL when the mutex was not owned by the current thread at the time of the call and a conforming implementation must return that value. The interpretations committee believes that this is not what was intended and has referred the issue to the sponsor for consideration. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd2-32 Topic: Thread-Specific Data Key Creation Description 9945-1-amd2-95 #32 Topic: Thread-Specific Data Key Creation Description Relevant Sections: 17.1.1.2 Defect Report: ----------------------- 6. Section 17.1.1.2, Thread-Specific Data Key Creation Description The description of thread-specific data destructors, somewhere along the line, lost the original intent of the working group, that the implementation shall set the thread-specific data value to NULL prior to calling the application's destructor routine. The standard currently (and incorrectly) requires that the application set the value to NULL within the destructor in order to avoid infinite looping or memory leakage. The standard should be corrected to require that the implementation SHALL set the value to NULL before calling the application destructor function. REF: page 343, section 17.1.1.2, lines 20-33 Interpretation response ------------------------ This is a duplicate. See 9945-1-amd2 Interpretation #8. Rationale ------------- None. _________________ end of SC22 N2594 _______________________________