Am Sun, 24 Jul 2016 13:03:01 +0000 schrieb Martin Nowak <[email protected]>:
> On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote: > > I'm interested in feedback on this library. What is it missing? > > How can be better? > > I think making the actual read/write/open/accept/et.al. functions > used to talk to the kernel pluggable would be a good extension > point to hook in evented/threaded IO frameworks. > This restricts the async integration to synchronous APIs, e.g. > suspendable Fibers or async-await, but that might be a reasonable > choice over nodejs-style inversion of control. > Can you please elaborate why this is useful? As streams already provide a source-independent way to process data it should always possible to just implement another stream to wrap low level calls. So why add another API layer? And if the API slightly varies (e.g. different open flags) implementing another wrapper is much simpler than having one wrapper dealing with different low level functions.
