D and Async I/O

[ikod]

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