Austin Group Minutes of the 24 June Teleconference Austin-215 Page 1 of 1 Submitted by Andrew Josey, The Open Group. June 25, 2004 Attendees Andrew Josey, The Open Group Don Cragun , Sun, PASC OR Joanna Farley, Sun Mark Brown, IBM, TOG OR Apologies Nick Stoughton, USENIX, WG15 OR Dave Butenhof, HP Ulrich Drepper, Red Hat Draft Status --------------- No status from ANSI on the ISO status of TC2. Defect Report Processing ------------------------- The group picked up on the latest batch of defect reports, which are available at the following URL: http://www.opengroup.org/austin/aardvark/latest/ XBD ERN 7 , BRE nested subpatterns (XBD BRE defn vs regcomp()) OPEN We decided to leave this open until the next meeting XBD ERN 14 netdb.h s_port description OPEN Sounds correct, but need more input on this item, leave open for one more meeting XSH ERN 39 deadlock detection for pthread_mutex_setprioceiling() OPEN This was discussed on the list since last time. Response from DB is included below: There's no particular need for pthread_mutex_getprioceiling to lock the mutex, though that would be one way to ensure memory coherency if there's any chance in the implementation of word tearing or other artifacts. As long as the access is atomic, though, I see no need for synchronization -- the result may be out of date and useless, but this will be true anyway after unlocking. We might fix this, actually, by requiring that pthread_mutex_getprioceiling be called with the mutex locked; the result would then be both coherent, and also valid until the caller chose to unlock. But the most likely action the caller might want to take would be to adjust the prioceiling... which cannot be done currently while the mutex is locked. The suggestion of defining an additional function to operate on a mutex that's currently locked is not a bad one. However I don't think it's a good idea to redefine pthread_mutex_setprioceiling to automatically determine whether the caller owns the mutex and behave appropriately. The working group has always strongly opposed a requirement on any implementation to maintain mutex ownership for default mutexes. (Ownership is clearly required for recursive, error check, and priority inheritance mutexes; however unlike priority ceiling none of these can be dynamically enabled on an existing "normal" mutex.) While I wouldn't necessarily object to adding a universal requirement for tracking ownership, we should be cautious, and I don't think this alone is sufficient justification for such a change in direction. Clearly it's possible for pthread_mutex_setprioceiling() to successfully lock, modify, and unlock a RECURSIVE mutex that's already locked, and perhaps it makes sense to say that directly. Performing this operation on any other locked mutex ought to be specified as "undefined". I think these two details should be "obvious" from context, and could be added as editorial clarification. Adding a new interface to change the attribute for a locked mutex is a bigger deal, but I agree it could be useful. Leave open for one more meeting XSH ERN 41 exit Reject The omission of the exit() function is intentional XSH ERN 42 sigpause and process signal mask OPEN Ask Dave Butenhof to take a look at this one. XCU ERN 21 awk what does srand() time of day mean Reject The standard does not specify what it means and that is intentional. To specify the means would mean specifying the implementation. XCU ERN 22 awk and hexadecimal handling OPEN We agree there is an inconsistency in the rationale that needs to be fixed. We need to investigate whether there are other inconsistencies in the normative text. Leave this open. Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. Andrew will generate some new interpretations. There are a number of open action items outstanding: 1. Don Cragun Pathname Resolution proposal 2. Larry Dwyer system() and threads 3. Joerg Schilling wording for XCU ERN 1 pax The next teleconference call is scheduled for July 15 2004