Asynchronicity in D

Aleksandar Ružičić ruzicic.aleksandar at gmail.com
Thu Mar 31 08:20:28 PDT 2011


I really like design of node.js (http://nodejs.org) it's internally
based on libev and everything runs in a single-threaded event loop.
It's proven to be highly concurrent and memory efficient.

Maybe a wrapper around libev(ent) for D ala node.js would be good
solution for asynchronous API, other than thread approach (I always
like to have more than one option and choose one which suits better
for concrete task I'm dealing with).

Whatever solution to be chosen I'd like to have an API like this:

readTextAsync(filename, (string contents) {
   // do something with contents
});


On Thu, Mar 31, 2011 at 2:04 PM, Piotr Szturmaj <bncrbme at jadamspam.pl> wrote:
> Max Klyga wrote:
>>
>> I've been thinking on things I can change in my GSoC proposal to make it
>> stronger and noticed that currently Phobos does not address asynchronous
>> I/O of any kind.
>>
>> A number of threads on thid newsgroup mentioned about this problem or
>> shown ways other languages address asynchronicity.
>>
>> I want to ask D community about plans on asynchronicity in Phobos.
>> Did somenone in Phobos team thought about possible design?
>> How does asynchronicity stacks with ranges?
>> What model should D adapt?
>> etc.
>>
>
> Yes, asynchronous networking API would be more scalable. If you're
> collecting information about async IO, please take a look at libevent and
> libev, also NT's completion ports, FreeBSD's kqueue and Linux epoll.
>
> Protocols implemented using event-driven APIs should scale to thousands of
> connections using few working threads. Moreover async protocols could be
> wrapped to be synchronous (but not other way around) and used just like well
> known blocking API's.
>
> Basically, while using async IO, you request some data to be written and
> then wait for completion event (usually by callback function). Then you
> request some allocated buffer to be read and then you wait until network
> stack fills it up. You do not wait for blocking operation like with using
> send() or recv(), instead you may do some useful processing between events.
>


More information about the Digitalmars-d mailing list