Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: james (james_at_[hidden])
Date: 2014-07-02 01:20:20

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.

I certainly wouldn't welcome something that didn't work well on Windows, and
last time I tried to integrate a different sort of stream, I gave up in 
a maze of twisty
little templates.

It might be possible to enumerate a bigger 'world view' of devices to 
include
files, named and anonymous pipes, serial ports, subprocesses (if not simply
done with pipes), shared memory queues, general signalling semaphores and
so on - but even that is painful.  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).

Its not clear how to handle interaction with devices that have a 
separate async
error channel (whether OOB data, or a pipe to a subprocess stderr, say) 
despite
the subprocess case being rather common in real use.

It also seemed to me to be taking template use out of its comfort zone.  I'm
sure many of us have written C++ IO wrappers many times over the last 20
years or so, and they were probably structured with C++03 facilities and 
rather
limited use of templates.  Why that should so so unfashionable beats me if
we end up with code as 'maintainable' as ASIO.  That's a view that 
applies to
plenty of Boost (and its why I'd generally choose Poco when possible) but in
this case 'more so' because arguments about having the compiler remove
overheads are somewhat weaker in the presence of IO operations.

James