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.
