Asynchronicity in D

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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

Ok.  If there are any enhancements that would make asyncBuf work better for this,
let me know.