2 Jul
2014
2 Jul
'14
1:17 p.m.
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/