This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Networking TS implementation


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 [1] library?

Yes.

> 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
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4399.html is
the most recent publicly-available draft.


> standard eventually include something similar to tasks implemented in
> Microsoft's casablanca (aka cpprestsdk) [2] or futures/promises in the seastar
> library [3]?

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 [4]?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]