[Posix-c++-wg] Minutes of the Frankfurt meeting

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please find below the minutes of the Frankfurt meeting in text form.  On
the Dinkumware wiki it looks much nicer and is more readable.  If you
don't have access to that wiki but think you should have, contact me off
the list.  It's not my machine and I cannot just give out the login
details on this list.

Send comments about the minutes etc to this list.  If something has to
be brought up at the next meeting make sure I added it to the agenda for
the next meeting when I send it out.



POSIX C++ Binding Working Group Frankfurt 2009

Friday, 2009-07-10

Meeting location: Interactive Data Managed Solutions AG,
Sandweg 94, 60316 Frankfurt am Main, Germany

Attendees (in alphabetical order of last name):

    * Lawrence Crowl, Google crowl@xxxxxxxxxx
    * Ulrich Drepper, Red Hat drepper@xxxxxxxxxx
    * Jens Maurer, on vacation Jens.Maurer@xxxxxxx
    * P.J. Plauger, Dinkumware pjp@xxxxxxxxxxxxxx
    * Tana Plauger, Dinkumware tana@xxxxxxxxxxxxxx
    * Detlef Vollmann, Siemens dv@xxxxxxxxxxx (joined at 10:22 hrs)
    * Michael Wong, IBM michaelw@xxxxxxxxxx

Minutes by Jens Maurer

    * POSIX C++ Binding Working Group Frankfurt 2009
          o Agenda
          o Welcome, Introductions
          o Review of minutes of New York meeting
          o Agree on agenda for the meeting
          o Review action items
          o Presentation of progress in ISO C++
          o Review submitted proposals
                + Device abstraction (Pedro LamarÃo)
                + I/O library (Pedro LamarÃo)
                + Sketch for a POSIX/C++ Event Notification Library
                  (Pedro LamarÃo)
                + WG21 N2178 Proposed Text for Chapter 30, Thread Support
                  Library [threads]
          o Assignment of work
          o Next meeting
          o Action items for the next meeting

Agenda

    * Welcome, Introduction
    * Review of minutes of New York meeting
    * Agree on agenda for the meeting
    * Review action items
    * Presentation of progress in ISO C++
    * Review submitted proposals:
          o Device abstraction (Pedro LamarÃo)
          o I/O library (Pedro LamarÃo)
          o Event Notification Library (Pedro LamarÃo)
          o WG21 N2178 Proposed Text for Chapter 30, Thread Support
            Library [threads]
    * Assignment of work
          o Review overall progress of POSIX/C++ group
    * Next meeting

Welcome, Introductions

Ulrich Drepper called the meeting to order at 10:04 hrs.

Review of minutes of New York meeting

Ulrich moves to approve last meeting's minutes. Unanimously approved.

Agree on agenda for the meeting

Unanimously approved.

Review action items

    * Ulrich to post the New York minutes to the POSIX/C++ mailing list
      --- will do that today.
    * shared_mutex is a bad name (process-shared mutex), Jens to point
      that out on the WG21 -lib reflector --- done.
    * Jason to ask ELF group for a new weak symbol type that does "deep
      resolution" necessary for C++ plugins --- done.
    * Everybody: review Pedro's Event Notification Library --- few
      people did.

Other action items were forwarded to next meeting.

Ulrich: ELF is fracturing, lots of vendor-specific
extensions. Since SCO started the lawsuits, nobody talks to them
any more, and they kept the ELF specification.

Lawrence: The dynamic library paper needs a mapping from the
desired semantics to the features of the binary formats /
loaders.


Presentation of progress in ISO C++

    * No WG21 meeting since the New York POSIX/C++ meeting.
    * Lawrence: The issues with concepts has a decent chance to delay
the C++0x standard. The concurrency area seems to be stable, except for
asynchronous futures, which turned out to be much more subtle than
anticipated. Resources associated with thread-local variables may have
impact on the OS side; a library loses control over the lifetime of
these. Not much else has happened on the WG21 reflectors that affects
POSIX/C++.


Review submitted proposals

Device abstraction (Pedro LamarÃo)

See The Device Abstraction by Pedro LamarÃo.

    * Ulrich, Lawrence: Names are unified (for example
      read/readv/recvmsg).
    * Jens: Mapping out the space can be done with concepts, we can
      decide on concepts or polymorphic classes later.
    * Ulrich: recvmsg() has a feature to disable SIGPIPE if the peer
      goes away, so maybe that is better than read() for networking.
    * Ulrich: A general zero-copy interface would say "use this buffer
      (for the OS to fill), or the OS gives me a pointer to a better
      buffer"
    * Jens: three layers: basic file descriptor interface, buffers on
      top, formatting on top.
    * Lawrence: Would like to see bottom-most layer, but buffers might
      be useful to include to fold in zero-copy.
    * Lawrence: Don't be afraid of to add low-level functions,
      programmers need to make an informed decision.
    * Ulrich: Getting away from the memory management issues for the
      user is the central issue. So we should provide an (optional)
      "buffer" layer.
    * Jens: Are we prepared to discuss proposals that are not a proven
      design?
    * Lawrence: Yes.
    * Ulrich: In this particular case, yes, everybody does it this way.
    * Bill: We are standardizing existing practice here.
    * Jens: We need a hierarchy of concepts. Ulrich: see I/O library
      paper.
    * Moving to the I/O library paper.


I/O library (Pedro LamarÃo)

See I/O Library (Pedro LamarÃo)

    * Ulrich, Jens, Detlef: We need a whole hierarchy of concepts, for
      example LinearFile, Seekable, Mmappable, Socket. Maybe these are
      dimensions, not a hierarchy.
    * Jens: We (of course) also need to have specific classes, for
      example a "class file" that implements Seekable, Mmappable, etc.
    * Ulrich: We could check for seekability in the constructor and
      throw an exception, but that would be additional checks which are
      a cost burden.
    * Jens, Ulrich: Is this adding enough benefit above and beyond
      POSIX/C to warrant inclusion in POSIX/C++?
    * Jens: We must differentiate error conditions, some condition might
      be an exception for client A and a regular situation for client B
      (for example, EAGAIN or EINTR).
    * Ulrich: Maybe have a separate class that automatically retries
      upon EINTR.
    * Ulrich: Different proposal: Just have global functions that wrap
      the POSIX/C functions.
    * Jens: not very user-friendly, think ambiguities in signatures with
      POSIX/C when "using namespace posix". Do not pursue.
    * Jens, Ulrich: Advantages: exceptions, fixing EINTR, unification of
      names, looks C++-ish, (polymorphism: feature, not a benefit)
    * Jens: I don't anticipate that the POSIX/C++ specification will
      have a class or function template that will have a template
      parameter requiring Seekable. This makes it harder to get the
      concepts right.  Other than that, no issue with providing concepts
      that are of use to users only.
    * Lawrence: We want both concepts and polymorphism.
    * Jens: If we want to pursue the machinery proposed in this paper,
      we must assign someone from this group to work with Pedro and
      progress the paper.

(lunch break 12:35 - 13:45 hrs)

    * No volunteer showed up to work with Pedro, maybe on the mailing
      list.
    * Ulrich: Turn-around of 4 months (until the next meeting) is much
      too long to make good progress.
    * We invite Pedro to initiate discussion on the mailing list.

(11:05 - 14:11 hrs)


Sketch for a POSIX/C++ Event Notification Library (Pedro LamarÃo)

See Event Library (Pedro LamarÃo)

    * Ulrich: select and poll have issues: Big argument lists have to be
      parsed over and over again. Fixes include kqueue (BSD), epoll
     (Linux), /dev/epoll (Solaris). A registration facility is used.
    * Detlef: We should be able to register a std::function as a
      callback.
    * Ulrich: Can be salvaged, say with a flag which event has been
      processed by callback.
    * Jens: There is no definition of concept EventSource.
    * Ulrich: "flags" should be typed better (enum?)
    * Ulrich: We agree on the "EventSource" mechanism to support other
      stuff such as Signals etc. (not currently supported by POSIX with
      select/poll-style waiting).
    * Ulrich: Also implementable with select or poll, but epoll and
      friends is much more efficient (where available).
    * Ulrich, Jens: We should make a proposal for POSIX/C to support
      epoll or similar in parallel to further work on this library.
    * Jens: use std::vector instead events array with count in wait()
      functions.
    * Bill, Jens: We need to have a function parameter "count == how
      many events max do I want to receive", plus the std::vector
      container.
    * Detlef: Have an output iterator for more flexibility?
    * Jens: Would require an additional copy from the temporary result
      storage of the actual system call to the output iterator.
    * Bill: So a std::vector seems adequate, do not pass on the C-style
      array/pointer. We don't need the std::size_t return then, but we
      still need a timeout indication.
    * Detlef: Don't use std::sigset_t, it's not in ISO-C, it's in
      POSIX-C, so remove "std::".
    * Jens: Maybe have a C++ interface for sigset_t to avoid all the
      strange macros. Different topic.
    * Ulrich: Can we pass 64bit quantities in event_data on a 32bit OS,
      in general? Maybe not rely on this and just use "unsigned long"
      instead of uint32_t and uint64_t.
    * Ulrich, Detlef: Integrate automatic callbacks by another add()
      overload taking a std::function and extending wait() by internally
      determining in an efficient way whether one of the returned events
      is an "automatic" one (with callback). Then, remove all events
      from the result set that have a callback after calling the
      callback. This needs separate storage in the poller class, because
      there are no bits to spare in the OS interface. This should be a
      separate class (not publicly derived) to avoid the extra cost when
      not needed.
    * Detlef: We need two concepts as well, a Poller and
      PollerWithCallback.
    * Ulrich: A timeout for the timed variants is not an error, should
      not throw an exception. Maybe enumerate all errno cases and
      explain whether an exception is thrown or not.
    * Jens: The constructors need documentation / description, maybe
      other member functions, too.
    * Ulrich: This is maybe based on an old version of the epoll
      interface, there is no "size" parameter in the constructor any
      more, instead there is a "flags" parameter which actually has a
      flag defined.
    * Jens: Finds the space between the function name and the opening
      parenthesis odd.
    * Ulrich: It's GNU convention.
    * Jens: I told you it's odd.
    * Jens: The class names need revision, we should do that next time.

(14:12 - 15:16 hrs)


WG21 N2178 Proposed Text for Chapter 30, Thread Support Library [threads]

See WG21 N2178 Proposed Text for Chapter 30, Thread Support Library
[threads]
(Peter Dimov)

    * Consensus: Point Benjamin to the paper, maybe there are some
      mapping ideas in there. Otherwise, not for this group.


Assignment of work

    * Ulrich: Do we think we make sufficient progress? The project is
      termed for four years, 2+ years are already over. We must have a
      specification before the deadline so that people can implement it
      and sanity-check it.
    * Jens: We need both review capacity and paper authors/editors.
    * Michael: IBM is here, so why is HP or Sun not here?
    * Jens: Go in hibernation for a year?
    * Ulrich, Tana: No, keep doing this to track WG21 developments.
    * Ulrich: Networking interface is important for users.
    * Lawrence: Problem with dynamic libraries is that it requires
      compiler support. Fortunately, most of the support is already
      present (attributes etc.), but still needs compiler frontend work.
    * Consensus: Keep going, ask IEEE for a time extension.


Next meeting

WG21 meeting is Oct 19 - 24, 2009 in Santa Cruz. Agreed to have
POSIX/C++ meeting Sun, Oct 18, 2009, presumably in Silicon Valley.


Ulrich closed the meeting at 16:14 hrs.


Action items for the next meeting

    * Benjamin to ask Detlef about his shared-memory interface ---
      Detlef sent it to Benjamin, processing still to be done.
    * Benjamin to ask for an LWG issue to permit throwing std::bad_alloc
      (in case of heap allocation failure ENOMEM).
    * pthread_mutex_t being an array: Benjamin to add such a prohibition
      to the revision of D011.: revisit for mutex proposal, Darwin has
      issues with that.
    * Benjamin to extensively revise D011 mutexes and
      condition_variables.
    * "mutex / timed_mutex / recursive_mutex: Lawrence to ask Howard
       Hinnant about adding inheritance relationships in standard
       classes. (permit common base type): still open
    * Ulrich to send information about the new ELF weak symbol type
      "unique" that does "deep resolution" necessary for C++ plugins
      to the POSIX/C++ mailing list.
    * Lawrence will address Benjamin to specify the point in time that
      destructors of POSIX setspecific/getspecific thread-specific data
      are run in relation to other objects on the C++ level (for
      example, thread-local data or global data).
    * Find a volunteer to work with Pedro on I/O library.
    * Ulrich to ask IEEE for a time extension for the POSIX/C++ project.

- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpzVB8ACgkQ2ijCOnn/RHRlawCgqCVewEBh+/rnc6aHoT71YQsV
4sUAn1+I7RbCBcNSffdVg/otPcB24SSI
=jiv0
-----END PGP SIGNATURE-----

_______________________________________________
Posix-c++-wg mailing list
Posix-c++-wg@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/posix-c++-wg