Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-07-02 03:31:44

On 2/07/2014 17:20, james wrote:
> On 30/06/2014 21:09, Niall Douglas wrote:
>> I think the wicked hard problem with ASIO will be deciding what
>> subset of it to standardise. For example, I would wonder if strands
>> or coroutines or any of the Windows support would make it.
> It seems to me that unless you either:
>   - make it easy to extend the set of 'devices' it can talk to
> or
>   - standardise a cross-platform 'device' concept that allows
> straightforward extension
> (both of which are hard) then it shouldn't be in the standard at all.

It doesn't actually require all that much code (lots of little pieces, 
mostly) to implement a different type of stream (I've done it a few 
times), although it's true that several parts are unobvious and it could 
probably do with an example.  (The "Services" example is close but not 
quite the same thing.)

Where it's a little more annoying is that the implementation details do 
a lot of accessing of *other* implementation details (presumably for 
performance reasons), which both makes them a bad place to look for 
examples of how to do it properly from "outside" of ASIO, and when you 
want something almost-but-not-quite like one of the existing classes, 
particularly when they have an internal base class that would have 
actually helped (but isn't safe to rely on from outside, of course). 
But you get that with many libraries.

> Not least, you can't integrate all of these onto a single event
> manager on any platform (eg on *nix, sysv shm queues etc, AIO events
> and semaphores don't mix well, and IOCP doesn't work with all handle
> types on Windows either).

It's possible to integrate (almost?) anything, but sometimes it carries 
a management or performance cost (eg. something that provides a 
synchronous-only custom API can be integrated into ASIO and made 
asynchronous, at the cost of adding an internal worker thread to call 
that API for each in-progress operation on that type of object; note 
that it's not just the cost of the thread, but also will require a 
double wakeup to service the completion, which adds latency). 
Completions can be posted from one service to another in a similar (but 
more elegant, if not identical) manner to the classic self-pipe trick.