Austin Group Minutes of the 11 May Teleconference Austin-298 Page 1 of 1 Submitted by Andrew Josey, The Open Group. May 19, 2006 Attendees Andrew Josey, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Don Cragun , Sun, PASC OR Ulrich Drepper, Red Hat Mark Brown, IBM, TOG OR Action item review --------------------- ACTION AI-2006-02-04: Nick Stoughton to submit an aardvark against link() when the appropriate time is reached w.r.t. approval of strawman 2. STATUS: OPEN ACTION AI-2006-02-28: AJ to filter the XSH, XCU and XRAT aardvarks for SD5 and interps material. STATUS: OPEN, ongoing in progress Austin/280r1 is the latest notes arising from SD5,Andrew has now completed this and that document is frozen since he has handed it over to Cathy for the draft 1 edit. A new document will be started with issues arising from SD5. ACTION AI-2006-04-01: Nick Stoughton/Andrew Josey to send reports to SC22 prior to the Sep 2006 SC22 Plenary (due date: July 2006) STATUS: OPEN PASC ---- Andrew noted that he has produced the first draft of the PASC PAR as Austin/296. We need everyone to review this. The PASC PMC criteria still have to be created. http://www.opengroup.org/austin/docs/austin_296.pdf Under 5.2 clarify SD5 with (technical issues log) in parentheses (and fix that in the title of SD5 so it corresponds) Needs update to 5.4 The purpose of the proposed standard is to revise 1003.1-2001 to include additional interfaces that have become widely adopted and to address known issues with the existing standard. Action: AI-2006-05-01 AJ Update the draft PASC PAR Action: AI-2006-05-02 AJ to produce draft PMC criteria Issues with Austin 280r1 (notes arising from SD5) ------------------------------------------------- http://www.opengroup.org/austin/docs/austin_280r1.txt SD5 XSH ERN 120 An comment had been raised on the proposed APPLICATION USAGE for sched_yield. It was agreed to leave this open until next time. It looks like we need further input from the SSWG Realtime . Action: AI-2006-05-03 AJ to send XSH ERN 120 issue to SSWG Realtime mailing list What should be the req'd behavior when threads are implemented but the process scheduling option is not, note that in that case there is no definition of thread list . Note that the description explicitly mentions thread list: The sched_yield() function shall force the running thread to relinquish the processor until it again becomes the head of its thread list. It takes no arguments. It might be that we need to redefine thread list, so it has meaning when the process scheduling option is not defined. Defect Report Processing ------------------------- We picked up on recent aardvarks http://www.opengroup.org/austin/aardvark/latest/ XSH ERN 129 twalk et al OPEN A new call to tsearch or tdelete makes the pointers obtained from other tfinds and twalks invalid A proposed change is as follow: After line 47554 on 1527 If tsearch adds an element to the tree, or tdelete successfully deletes an element from the tree, the concurrent use of the tree in another thread, or use of pointers produced by a previous call to tfind or tsearch, produces undefined results A question was raised over whether these functions are thread safe. Even if thread safe the tree can still be altered as noted above. This needs some discussion. Leave open for the next call. Left open from the previous meeting to address next time: XCU ERN 22/23 awk OPEN XCU ERN 57 mv OPEN Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. The next call will be 25th May irc://irc.freestandards.org/austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic