This is the mail archive of the
mailing list for the libstdc++ project.
Re: Networking TS implementation
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Mikhail Maltsev <maltsevm at gmail dot com>
- Cc: Jonathan Wakely <jwakely at redhat dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Sun, 18 Oct 2015 22:47:51 +0100
- Subject: Re: Networking TS implementation
- Authentication-results: sourceware.org; auth=none
- References: <20151017154615 dot GH12094 at redhat dot com> <5622962E dot 5080809 at gmail dot com> <CAH6eHdTgw3-u=NDi=2cyAj6JnRvnH=R1mDV_pG92uChHqj1rGw at mail dot gmail dot com> <5623C8BE dot 5000001 at gmail dot com>
On 18 October 2015 at 17:28, Mikhail Maltsev wrote:
> Again, I'll look at the TS in more detail to see, how to implement that and to
> understand all the caveats. For now I got an impression that such implementation
> is also possible (and not too hard) with some custom CompletionToken-s, I'll try
> to experiment with it.
I thin it's doable, but I'm not sure how. I'll talk to the author
about it when I see him later today.
> But in order to start we need some implementation to work on. You mentioned that
> you have some prototype for Networking TS. Could you share it? FWIW, it should
> have some differences with asio (e.g., const_buffers_1 and mutable_buffers_1
> have been dropped).
Yes, I've implemented the proposal I linked to, not Asio.
I'll probably commit it to GCC trunk later this week if there are no objections.
> And another important question is: now hard is it to get some changes integrated
> into the upstream? It's fairly easy with GCC: I send a patch, the maintainers
> review it, if they find it reasonable, I fix their remarks and eventually commit
> it. IIUC, the process is the same with the TS implementation.
The TS implementation I'm talking about is going to be part of GCC, it
will have the same process as the rest of GCC (although as noted for
the Filesystem TS at
the API and ABI may be less stable, and so it might be easier to make
breaking changes than for the rest of libstdc++).
> But what about the TS API? Will it require much more bureaucracy? How large is
> the group of "decision makers" (i.e. the folks who eventually decide what goes
> in and what does not)?
It's going through a similar process as the C++ standard, but the
output is a separate document, not part of the standard. Due to the
experimental nature of a TS people are a bit more willing to put
things in that might not be perfect, because we can revise a TS a bit
easier than the standard, and we are not obliged to include anything
from a TS in the standard.
The committee meetings have 100+ people, and far more participating in
email discussions, but not all of them participate in the sub-groups
dealing with the Networking TS (which have generally happened in the
Library Evolution Working Group so far). See
https://isocpp.org/std/the-committee/#Subgroups for more information
on the committee etc.