Asynchronicity in D

[Andrei Alexandrescu]

On 3/31/11 11:43 AM, dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> On 3/31/11 6:35 AM, 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.
>> I think that would be a good contribution that would complement Jonas'.
>> You'll need to discuss cooperation with him and at best Jonas would
>> agree to become a mentor.
>> I've posted a couple of weeks earlier how I think that could work with
>> ranges: the range maintains the asynchronous state and has a queue of
>> already-available buffers received. The network traffic occurs in a
>> different thread; the range throws requests over the fence to libcurl
>> and libcurl throws buffers over the fence back to the range. The range
>> offers a seemingly synchronous interface:
>> foreach (line; byLineAsync("http://d-programming-language.org"))
>> {
>>      ... use line ...
>> }
>> except that the processing and the fetching of data occur in distinct
>> threads.
>> Server-side code such as network servers etc. would also be an
>> interesting topic. Let me know if you're versed in the likes of libev(ent).
>> Thanks,
>> Andrei
>
> Is this basically std.parallelism.asyncBuf
> (http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html#asyncBuf) or something
> different?

asyncBuf would be an excellent backend for that, but the entire thing 
needs encapsulation so as to not expose user code to the risks of undue 
sharing.

Andrei