On Monday, 11 May 2020 at 21:15:28 UTC, Steven Schveighoffer wrote:
On 5/11/20 3:46 PM, ikod wrote:
On Monday, 11 May 2020 at 17:34:41 UTC, Jacob Carlborg wrote:
On 2020-05-11 16:44, Russel Winder wrote:

Crickey, a third option. This wil increase my dithering! ;-)

Forth: Mecca [1] :)

[1] https://github.com/weka-io/mecca

And probably more. At least I also have my async library for network IO.

It would be nice to have well defined interface for async io. That will allow to choose and test different implementations.

Part of the problem is the different APIs that async libraries use. Some use callbacks, some use fibers, maybe some async/await forms.


callbacks are basic building blocks, which should be supported anyway.

std.io aims to provide a common interface for async and sync i/o, where you choose the driver at the beginning of your program. If written properly, it could be a nice way to test

My library also can work in this modes. There are low-level "sockets" which can be used only with callbacks, and also high-level sockets which can be used in "sync" mode in fibers or even without fibers as a replacement for std.socket's. Here is simple example where callback-based Timer used to build "sync" sleep:

void Sleep(Duration d) {
    if ( d <= 0.seconds) {
        return;
    }
    auto f = Fiber.getThis();
    if (f is null)
    {
        // called not from fiber/task, there is no concurrency,
        // use plain old sleep
        Thread.sleep(d);
        return;
    }
    // otherwise we yield and return to current fiber
    // later, when timer expires (using event loop)
    auto callback = delegate void (AppEvent e)
    {
        assert(e == TimeoutExpired);
        f.call();
    };
    auto t = new Timer(d, callback);
    getDefaultLoop().startTimer(t);
    Fiber.yield();
}


code with various drivers without having to change code. It would require a Fiber-based approach, however.

I have not added an async driver (yet), but it's in my somewhat immediate plans to do so, as I want to start using this more (along with iopipe). Contributions would be welcome.

initially very few interfaces required - like start/stop for Timer, start/stop for SignalHandling, start/stop for file/socket poll.


https://github.com/MartinNowak/io

-Steve


Reply via email to