[GSoC Proposal draft] High-Level Networking

[Jose Armando Garcia]

That all sounds good. I would add Flash to your investigation:
http://www.cs.princeton.edu/~vivek/flash/. There is a must read
research paper for any distributed system person at:
http://www.cs.princeton.edu/~vivek/flash_usenix_99/

On Fri, Apr 1, 2011 at 8:17 PM, Max Klyga <max.klyga at gmail.com> wrote:
> Since my proposal theme shifted a little towards asyncronicity, I've been
> eagerly consuming information that might help me with this.
>
> I would be glad to know if I am moving in to the right direction. Comments
> are welcome.
>
> So far, here is the status report:
> I looked at approaches to asyncronicity in Ruby's NeverBlock, C#, Qt,
> Boost.ASIO
>
> NeverBlock uses Fibers for managing asyncronous operations. One fiber acts
> as a scheduler, polling async operations for complition and resuming other
> fibers as needed.
>
> C# uses several approaches to asyn operations. There are three common
> patterns now:
> - Split async functon in two (BeginFoo, EndFoo). Begin... function returns
> IAsyncResult object and shedules operation in process-default thread pool.
> End... function takes IAsyncResult object that we got earlier and, if
> operation was complited, returns computation results or blocks until the
> operation is completed. All exceptions thrown in asyncronous operation are
> stored and rethrown when user calls End... function.
>  Any function can be called asyncronously using built in wrapper.
> - Some classes provide the following interface for time consuming
> operations:
>   class Foo {
>       bar(...); // blocking operation
>       asyncBar(...); // asyncronous operation
>
>       cancelAsync();
>
>       barCompleted;
>
>       barResult;
>   }
> - Task-based asyncronicity, similar to std.parallelism. Async operations
> (BeginFoo, EndFoo) can be wrapped as a task and scheduled to be executed on
> user controlled task pools.
>
> Qt uses it's signal/slot mechanism for asyncronous operations. It's somewhat
> similar to C# events, or arrays of D delegates.
>
> Boost.ASIO is based on callbacks/delegates. It's implementation is based on
> proactor design pattern and doesn't use Fibers or Threads.
>
>
> I've also spent some time digging up info on event-based servers.
> This is my to-read list on this weekend:
>        [1] Ous96 John Ousterhout. Why threads are a bad idea (for most
> purposes). In USENIX Technical Conference (Invited Talk), Austin, TX,
> January 1996.
>        [2] Rob von Behren, Jeremy Condit, and Eric Brewer. 2003. Why events
> are a bad idea (for high-concurrency servers). In Proceedings of the 9th
> conference on Hot Topics in Operating Systems - Volume 9 (HOTOS'03), Vol. 9.
> USENIX Association, Berkeley, CA, USA, 4-4.
>        [3] Atul Adya , Jon Howell , Marvin Theimer , William J. Bolosky ,
> John R. Douceur, Cooperative Task Management Without Manual Stack
> Management, Proceedings of the General Track: 2002 USENIX Annual Technical
> Conference, p.289-302, June 10-15, 2002 (related presentation:
> http://www.cs.nyu.edu/rgrimm/teaching/fa03-web/091603.pdf)
>        [4] http://www.kegel.com/c10k.html
>        [5] http://tomasp.net/blog/csharp-fsharp-async-intro.aspx (I should
> look at how F# handles asyncronicity)
>
>