Lock-Free Actor-Based Flow Programming in D2 for GSOC2011?

[Piotr Szturmaj]

Kagamin wrote:
> Piotr Szturmaj Wrote:
>
>> Kagamin wrote:
>>> eris Wrote:
>>>
>>>> Windows uses a "proactor" model instead of reactor, so it schedules I/O first and
>>>> then waits for an IO completion flag. I've modified my reactor so that it presents
>>>> a reactor facade even on Windows systems.
>>>
>>> Huh? What does it change? IO is done pretty much the same on all systems: client requests an io operation, OS send the thread to sleep until the operation is complete.
>>
>> You mean synchronous blocking IO. Proactor in Windows means asynchronous
>> non-blocking IO (overlapped IO) and completion ports. Client may request
>> multiple IO operations and its thread is not put to sleep. Instead,
>> client receives all completed operations using
>> GetQueuedCompletionStatus() or using callback function.
>
>  From what I understand, reactor is meant to be synchronous?

Reactor is event handling pattern, when client specify event handlers 
like onRecv() and just wait for the events - these are delivered as soon 
as they arrive. Proactor on the other side requires that client issue 
each asynchronous operation manually - there will be no events delivered 
until client requests them.

For example in linux's epoll, events are delivered as soon as there is 
available data in the buffer (in level triggered mode). In Windows NT 
family recv event is delivered only after successfull call to WSARecv().

Proactor model has (a debatable) advantage of specifying data buffer 
before issuing async IO. This could avoid data copying in some 
circumstances, because IO manager can read data directly into that 
buffer. In reactor models (epoll) buffer is provided after IO completes. 
This involves copying of data from internal buffer to user's buffer.