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 10/18/2015 02:32 AM, Jonathan Wakely wrote:
> btw, the link in my original email has information relevant to all
> your questions.
>
Yes, but your answers were very helpful as a starting point for comprehending
this fairly huge standardese TS.

On 10/18/2015 02:30 AM, Jonathan Wakely wrote:
>> 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,
I agree, my knowledge of the TS is still cursory. But I'll study it in detail.

> 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.
(snip)
> I don't know anything about cpprestsdk but you can use a custom
> completion token to return other types of future.
Yes, what I also need in our project* [1], is to be able to use something
similar to when_all/when_any from the Concurrency TS with CompletionToken-s.

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.

In our project we are starting to pull in the pieces of asio. We started with
buffers for (at least partial) scatter/gather and also some trivial stuff like
network address to string conversions.

But what we really want is to get rid of our somewhat legacy* custom network
stack and event loop implementation.

> They might not. The point of publishing each piece of work as a
> separate TS is to get implementation experience and user feedback
I want our project to become one of the early adopters*. Of course, I don't make
such decisions alone (I'm just a developer, not a teamlead), but I have
convinced our team to start using asio, and there is consensus among us to
eventually migrate to the new event loop implementation, i.e. chances are that
my proposal of using this Networking TS will be accepted.
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).

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.

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)?

* - speaking for myself only!
[1] The project I refer to is a framework, which is used for implementing some
of high-load backend software of a (relatively small) social network,
https://corp.mail.ru/en/company/social ("My World")

-- 
Regards,
    Mikhail Maltsev


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