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.
