[GSoC Proposal draft] High-Level Networking

Max Klyga max.klyga at gmail.com
Fri Apr 1 16:17:48 PDT 2011


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)



More information about the Digitalmars-d mailing list