POSIX C++ Study Group

SC22 ballot document N4217 for IEEE P1003.1, Draft 3.

Meeting location: IBM Software Lab meeting room at 8200 Warden Avenue, Markham, Ontario, Canada.

Ulrich Drepper called the meeting to order at 9:41 hrs.

Minutes by Jens Maurer.

Introductions

Attendees (in alphabetical order of last name):

Don, Nick, Ulrich are part of the base working group for POSIX.

Others are are affiliated with WG21.

Lunch break is from 12:00 to 13:30 hrs. Hotel restaurants, shopping plaza at the intersection of highway 7 and Warden Avenue, and Chinese mall (on Warden Avenue towards Richmond) are available.

Ulrich: This is an official IEEE meeting. The task of the Study Group is to find out whether there is enough interest and create a PAR. In particular, we have to define the scope (as detailed as feasible), timeline, and officers of the Working Group.

Agenda

Lawrence's e-mail from Friday is more concerned with presentation/implementation details, no effect on agenda.

The agenda is unanimously agreed upon.

Presentation of different approaches

Nick: Formation of the Austin Group as a joint working group of ISO, the Open Group, and IEEE. Draft 3 is currently in simultaneous ballot in all three entities. For a POSIX/C++ binding, there are a number of approaches. Ada has a "thick" binding, i.e. it rewrote the entire POSIX standard in terms of Ada. Fortran did a "thin" binding, i.e. it just maps the syntax function-by-function to the C binding. Do we want a thick or a thin binding? Experience tells us that thin bindings are a lot easier to maintain. C++0x is already doing a lot of stuff that relates to POSIX, thus there is overlap between POSIX and C++0x efforts, for example threads. Maybe one approach is not to write a separate standard. Maybe make it part of C++0x, but the timetable may be prohibitive. Or produce a Technical Report. We should not have competing standards ("standard C++ threads" and "POSIX threads") that are mutually incompatible.

Are we doing the right thing, trying to come up with a separate International Standard for a POSIX/C++ binding?

Lawrence: C++ is aiming for generality, POSIX is aiming towards control.

Ulrich: We are envisioning an add-on extension integrated into the C++ facilities, similar to POSIX extending standard C functions.

Benjamin: We're going to see a lot more overlap between the C++ library and POSIX, e.g. system_error, threads, also C++03 locales. Some kind of study is warranted to make sure the same terms mean the same thing.

Bill: More of the POSIX interface is exposed in the C++ interface with C++0x. There have been serious efforts in the last quarter century that C, C++, and POSIX play together, but have clear division. Central question: Why do we want to have another binding document? What do you have to say in a POSIX/C++ document that is not better said in C or C++ or POSIX? Focus on the C++/POSIX interaction specialities.

Ulrich: We are not artificially introducing C++ bindings if the C binding is perfectly fine.

Nick: Good point about existing practice. In the POSIX world, a fundamental part is "Has this been implemented? How widespread is existing practice?". This approach came from experience in the early 90ies. We should keep the invention part to an absolute minimum.

Tana: If it's invented, there should be an implementation.

Ulrich: We should define what "existing practice" means, for example "one implementation, tested for half a year".

Bill: Speaking out for backward compatibility, important for his customer community.

Hans Boehm: In some places, we have to invent, because there is no existing practice that works.

Ulrich: Yes, but that does not exclude that there is an implementation at standards ballot time, otherwise it's out.

Nick: Wants to have the bar fairly high on the "existing practice".

Ulrich: C++ library group should not cave in to pressure, do it right instead of only having a minimal feature set in the next standard.

Lawrence: The library is much more embedded in the ABIs than most people seem to realize. ABI incompatibilities later will decrease the adoption rate. Therefore, we must plan for later changes now.

Ulrich: With advanced C++ features, this might be less of an issue than feared.

Thomas Witt: The time pressure is real, people have the need to do threading.

Bill: Different to "export" or other features, people have been doing threading for tens of years. The question is whether we can convince people to switch to the "standard" way of doing threading.

Hans Boehm: We see people use 99.9% percent solutions that don't work all of the time. We want to provide a 100% solution. Example: Interaction of static object destruction and threads that live until process end.

Ulrich: Need not to be covered in the C++ standard, can be covered in the POSIX/C++ binding.

Lawrence: Programmers need guidance on how to write good applications.

Ulrich: Disregarding systems programmers, the best advice to programmers is "don't use threads". OpenMP and other approaches provide a better service to programmers.

Lawrence: A lot of the current C++0x extensions are targeted to library developers, providing mechanism for higher-level libraries.

POSIX recent development

Ulrich: Some functions are deprecated in POSIX, but N2298 recommends them, e.g. strerror_r (it's an incomplete solution), replaced by strerror_l; rand_r (came from POSIX.1c, was a mistake), being removed from the standard (it only has a state of 31 bits); concept of thread-local locales (based on glibc implementation to handle C++ iostreams locales): locales are objects, you can pass them to functions, the default behavior is backward compatible.

Other new group of functionality: Have the current working directory play a lesser role (due to all threads sharing the same current working directory), so at-functions are added which take a directory file descriptor. Relative paths are interpreted relative to that directory.

Other major areas of improvement: secure string functions, robust mutexes (mutex in shared memory, lock held by a crashing process will be put in limbo state for another process to clean up).

Bill: There is no guidance in the C++ standard how to splice C++ locale objects with C locales. That work is probably worth doing.

Ulrich: Every single OS is going into the direction of making locales more explicit and separate objects.

10:41 hrs coffee break
10:54 hrs resume from break

C++ library recent development

Benjamin: C++03, C++0x, and TR paper queues that have or may have POSIX implications.

C++03:

C++0x:

TR2:

Modules TR:

Review of current threading ideas, APIs, and other approaches to parallelism.

WG21 N2320: Threading API

Benjamin: Higher-level C++ APIs for threading (no papers exist yet for either WG21 or POSIX), by creating a parallel STL: Take algorithms such as count, find, etc. from the STL and make them internally parallel, also for_each. The work is pioneered by Intel. This suggests another area of C++ work, for example for a TR.

Ulrich: This is the right level for an approach to parallelism in the C++ language, putting something more low-level in (i.e. an OS binding) is not the right level.

Tana: It's important not to fracture the C++ committee, because it's very diverse.

Ulrich: On the Sun platform, POSIX threads has dominated Sun threads for a lot of years.

Howard: There is pressure to ship C++0x with a threading API, joint EWG+LWG groups want futures and thread-pools, overruling library working group.

Bill: There is a lot of political manouverings going on in WGs. Higher-level thread concepts were sponsored by Herb and Bjarne.

Lawrence: A TR that changes the ABI is a non-starter. Some TR features require core language features, but those core language features will only be exercised by the TR features, and you can't fix the core language features in the TR.

Bill: The argument was that not providing thread pools in the standard, everybody will create their own incompatible version.

Ulrich: C++ will have the same problems as Java, eventually failing to provide interoperability.

Lawrence: "It's not going to work" is not going to convince the C++ committee, you need to name specific technical issues.

12:00 hrs lunch break
13:43 hrs resume from lunch break

Review of Evaluation Criteria

Now discussing N001, the annotated PASC PMC PAR Evaluation Criteria.

Target audience is IEEE (Institute of Electrical and Electronics Engineers) PASC (portable applications standards committee) SEC (sponsor executive committee).

1. Industry experience

2. Base document

5. Coordination plan

3. Realistic scope and timeline

4. Appropriateness and industry acceptance

Ok.

6. Community commitment

7. Within PASC scope

Yes.

8. Reasonable resource impact

Nick: We shouldn't drain resources from C++ nor POSIX.

Agreed on the words.

9. Test plan

No test specifications.

15:09 hrs coffee break
15:19 hrs resume from coffee break

Review of PAR form

Now discussing N002, the PAR form.

4.1: Can have individual (per-person) or organizational voting.

4.2: Expected Date of Submission for Initial Sponsor Ballot: March 2010

4.3: Projected Completion Date for Submittal to RevCom: June 2011

5.1: Approximate number of people expected to work on this project: 15

5.2: Scope of Proposed Standard

5.3: Is the completion of this standard is dependent upon the completion of another standard?

5.4: Purpose of Proposed Standard (the "why" question)

5.5: Need for the project

5.6 Stakeholders for the standard

6.1 Intellectual Property

7.1 Are there other standards or projects with similar scope?

7.2 Future adoption

7.3 health, safety, security, environmental

Consensus on the answers to the PAR form.

Introduction to C++ threads API proposals (Howard Hinnant)

Thank the host by acclamation.

Meet at the Primrose room today at 20:00 hrs, fed and watered, for further informal discussion.

Meet in the hotel lobby on Monday at 8:30 hrs for people who want to walk to the IBM facility together.

Adjourned the meeting at 17:09 hrs.

Additional informal evening meeting

Primrose room at Hilton Hotel.

Start at 20:05 hrs

Interaction of shared libraries and thread-local storage

Thread creation API (Howard)

Cancellation

22:41 hrs finish.