2 Jul
2014
2 Jul
'14
7:31 a.m.
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.