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 00:30:18 +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>
On 17 October 2015 at 19:40, Mikhail Maltsev wrote:
> On 10/17/2015 06:46 PM, Jonathan Wakely wrote:
>> It's still missing socket iostreams, parts of the use_future
>> completion token handling, and system_context needs some work
>> (currently it uses a "thread pool" hardcoded to one thread).
> Hi! I'm very interested in the networking part of the C++ standard, but
> unfortunately could not find much information on it's current status.
There is nothing in the standard, this is a proposed TS, which would
be a separate document from the International Standard.
> Perhaps you could help and shed some light on the situation:
> 1. Do I understand correctly, that the library part (especially the API) is
> mostly based on the asio  library?
> 2. What about futures/promises, i.e. some facilities for chaining async_result-s
> (IIUC, current std::future will not work well with asio Executor-s)? Will the
See net::use_future in the proposal. It might not be clear if you're
not familiar with the concepts, but you can pass net::use_future as a
completion token, which will cause a std::future to be returned, so
you can wait on that for the result. The completion handler itself can
be used to chain further operations when the first one completes.
If you want to chain std::future-type objects then see the draft
Concurrency TS. I think
the most recent publicly-available draft.
> standard eventually include something similar to tasks implemented in
> Microsoft's casablanca (aka cpprestsdk)  or futures/promises in the seastar
> library ?
I don't know anything about cpprestsdk but you can use a custom
completion token to return other types of future.
> 3. What about resumable functions support in the language itself? Which
> implementation is in favor? Is it N4134 ?
There are competing proposals.
> 4. How will all of the above work together?
They might not. The point of publishing each piece of work as a
separate TS is to get implementation experience and user feedback
before anything is added to the standard and set in stone. The
approach in one TS doesn't necessarily have to agree or interoperate
with the approach in another TS. They are experimental ideas and are
not intended to form a single, cohesive design.
I have been working on the Networking TS, I'm not the best person to
ask about the others.
You can follow their status at https://isocpp.org/std/status