Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-02 09:17:21

On 2 Jul 2014 at 6:20, james 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.

You must remember that from the perspective of ISO, the only 
engineering standards which exist are other ISO standards. That in 
this case equals POSIX. This is why I said that Windows support 
cannot be standardised and would have to be omitted.

Similarly, the cross-platform device concept you mentioned is already 
defined by ISO. It is the device concept implemented by POSIX. It 
does not include IOCP or any such equivalent (unfortunately [1]).

In this nothing would vary from the C++ 11 standard, or any other 
standard, all of which exclusively think in terms of POSIX. The only 
i/o concept is that of POSIX alone.

[1]: I would REALLY super love if POSIX defined BSD kqueues as the 
one, true, santified method of doing i/o multiplexing and deprecated 
select(), poll(), epoll() and all others as being nothing more than 
wrappers around kqueues. And for the love of god Linux needs to adopt 
kqueues already :(

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

ISO POSIX already specifies files, pipes, block devices, semaphores 
and all the other stuff you mentioned. Their support in an ASIO 
standardisation is straightforward.

The POSIX way of doing async file i/o is the aio_* POSIX API, and of 
course POSIX specifies file locking too. Both the aio_* and the file 
locking specifications do not work at all well with threading and 
would be useless to ASIO.

I, obviously enough, would like AFIO into the C++ 17 standard and 
with that we get a new standard portable API for async file i/o and 
locking which is ASIO compatible. But unless there is a sudden and 
massive uptick in the use of AFIO, it won't be popular enough to 
become eligible for standardisation.

> 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. 

I completely agree on this sentiment.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/