On Tuesday, 10 May 2016 at 13:34:36 UTC, chmike wrote:
> My initial question is if there is a working group I could join to work on this pure D async library. I'm interested in working on the subject.

Considering libasync is only native D async library supported by vibe.d right now, focusing on improving it is likely to be best course of action as it has highest chance of ending up base of Phobos std.async

On Tuesday, 10 May 2016 at 13:34:36 UTC, chmike wrote:
> vibed uses libevent, a C library.
>
> The discussion is regarding a possible pure D equivalent of libevent.
> libasync is an interesting proposal but it is apparently slower than libevent. I don't know the current status because vibed improved its performance in the last months.
>
> My initial question is if there is a working group I could join to work on this pure D async library. I'm interested in working on the subject.

if you used in unix(linux,bsd,mac),you can look our's event-net lib. now it is only epoll(linux), the kqueue(bsd and mac) is easy to support.
and now only timer and tcp.
It's like facebook/wangle(Netty + Finagle) smooshed together, but in D.

https://github.com/putao-dev/collie

On Tuesday, 10 May 2016 at 13:34:36 UTC, chmike wrote:
> vibed uses libevent, a C library.
>
> The discussion is regarding a possible pure D equivalent of libevent.
> libasync is an interesting proposal but it is apparently slower than libevent. I don't know the current status because vibed improved its performance in the last months.
>
> My initial question is if there is a working group I could join to work on this pure D async library. I'm interested in working on the subject.

from my experience its not really slower than libevent and it could be made
even faster by taking some time to profile it.
plus its battle tested in production and fully cross platform.

also, it will most probably not be your bottleneck.

On Thursday, 12 May 2016 at 14:02:30 UTC, Dsby wrote:
>
> https://github.com/putao-dev/collie

Thank you very much for this library I wasn't aware of.

I see it's using the Reactor pattern (select/kevent/epoll of Posix) by opposition to the Proactor pattern (IOCP on Windows)  [D. Schmidt et al, Pattern Oriented Software Architecture, Volume 2. Wiley, 2000].

In the Proactor pattern you pass a function and its parameters (e.g. buffer) to be executed asynchronously. In the Reactor pattern the user is notified when there is data to read.

The Reactor pattern is superior in many ways to the Proactor pattern (IOCP):

- There is no need to preallocate a buffer for all input channels that can stay idle for a long time. This doesn't scale well to million connections.

- There is no risk to pass a parameter (e.g. array) on the stack or destroyed before the function execution.

- It is possible to read into (or write data from) a transient storage on the stack (e.g. array or a struct) and benefit from RAII and less GC load.

Unfortunately Windows only provide the slow select() operation. User are advised to use the faster IOCP which I guess is there mainly for historical reasons.

So the first question to ask when designing an async IO system is if we go for a Reactor system or a Proactor system.

Nearly all async IO system (except libev) adopted the Proactor pattern to be compatible with Windows and its IOCP.

My feeling is that if we want to provide a simple, robust and scalable API, the Reactor pattern should be favored.

On Monday, 16 May 2016 at 17:08:32 UTC, chmike wrote:
> - There is no need to preallocate a buffer for all input channels that can stay idle for a long time. This doesn't scale well to million connections.

Can you request one byte and then read what was buffered?