== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 3/31/11 11:43 AM, dsimcha wrote: > > == Quote from Andrei Alexandrescu (seewebsiteforem...@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.