Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at