Austin Group Minutes of the 25 May Teleconference Austin-300 Page 1 of 1 Submitted by Andrew Josey, The Open Group. May 26, 2006 Attendees Andrew Josey, The Open Group Ulrich Drepper, Red Hat Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Don Cragun , Sun, PASC OR Glen Seeds, 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. (ongoing action) 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 second draft of the PASC PAR as Austin/296r1. http://www.opengroup.org/austin/docs/austin_296r1.pdf We reviewed it in the meeting. This is now considered ready to go to the PASC SEC. The first draft PASC PMC criteria is at http://www.opengroup.org/austin/docs/austin_299.txt We reviewed this. Recommended changes are as follows: Add the list of the 4 API standards from The Open Group to the Base documents section. Add ISO C and SSWG-RT as coordination points. For the list of organizations supporting the project in section 6, add: USENIX IBM Corporation Red Hat Inc. Sun Microsystems Inc In 9. strike the last sentence: "A parallel revision of 2003.1 may arise if sufficient interest and business relevance can be identified." Andrew will recirculate for a last call, and also to solicit further supporting organizations for section 6. Once approved by the SEC we should also submit this to ISO SC22 for information. Issues with Austin 280r1 (notes arising from SD5) ------------------------------------------------- http://www.opengroup.org/austin/docs/austin_280r1.txt We continued working the issue on sched_yield application usage: SD5 XSH ERN 120 Note from Dave B from the reflector in response to last week: The intent of the POSIX threads group, as a shorthand notational convenience, was that as of 1003.1 1996, ALL POSIX implementations are effectively treated as "threaded" and _POSIX_THREADS denotes only the ability to create and schedule more than ONE thread within each process. In this model, "processes" aren't interesting, and aren't scheduled; only threads. So regardless of the thread option there is always a "thread list" (which, like "process list" is an abstract shorthand notation anyway that's not intended to require a particular implementation). It's quite possible that this model wasn't made as clear as necessary; and certainly possible that the SUS merge/adaptation and subsequent editing has made it even less clear. It's also not unreasonable to decide now that some other documentation convention would be more appropriate. But saying "thread list if there are threads otherwise process list" everywhere that either term might be used just seemed ridiculous... ;-) --end of note A lengthy discussion occurred. The conclusion of which was as follows: A thread list is always there. Every thread in the system in a single threaded process is on a thread list. In the absence of the PS scheduling option whether threads from other processes will be on the same thread list is implementation defined. We need to add some rationale or application usage to make this clear. on XSH page 1261 Andrew to take action to propose rationale for review: Proposed RATIONALE/APP USAGE for XSH page 1261 The conceptual model for scheduling semantics in this standard defines a set of thread lists. This set of thread lists is always present regardless of the scheduling options supported by the system. On a system where the Process Scheduling option is not supported portable applications should not make any assumptions regarding whether threads from other processes will be on the same thread list. Question raised : Does anyone implement thread sporadic scheduling? Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. The next call will be 8 June 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