[Libevent-users] Add support for WINDOWS Overlapped IO

[Toby Douglass]

Zhu Han wrote:
> Toby,
> 
> Good work!
> 
> There is several questions for your implementation:
> 
> 1) If you play with the Completion port, there is no reason to use the
> hEvent  in the OVERLAPPED structure. Why do you use it?

I assumed it was used internally by the IOCP.  I'll investigate removing it.

> 2)I suppose socket_internal_iocp_read is called before you invoke the
> callback to let the callback consume the received data. Why do you call
> socket_internal_iocp_read firstly?

Well, socket_internal_iocp_read() issues a non-blocking ReadEx() on the 
socket.  The user could do this, but the API can do it for him without 
any loss of functionality.  So, when the user gives me a socket, I issue 
a read on it; then, when the read completes, I call the callback to pass 
him the data and issue another read.  This way, it's simpler and easier 
for the user; all he does is add his socket, and then that's it - the 
callback is called when data arrives.  He has nothing else to worry 
about or so.

> 3)Is there any plan to support all of the Async operations, such as 
> connect, listen, accept, read and write?

I added listen and accept last week, and I'm testing them now.  I didn't 
add connect, because ConnectEx() is XP and higher only (it's not 
available under w2k).  I've not added support for writes, because I 
think people generally issue blocking writes, since non-blocking means 
that if you return from a function which issues a send you have to 
ensure the lifetime of the buffer you've sent is non-local.

> BTW: your implementation has a lot of difference with libevent. The most
> important one is libevent is a "single-threaded event-driven" library. This
> could relieve the programmer from the burden of explicitly synchronization,
> althouth it can't explore the capability of SMP.

Mmm.  I can't see how a single threaded approach can work under Windows, 
since different blocking function calls are needed for different 
mechanisms - you can't block on WaitForMulitpleObjects(), select() and 
GetQueuedCompletionStatus() at the same time in the same thread.

I've not much read the source for libevent, though, so I don't know how 
it manages things internally.

Single-thread event-driven seems to me to basically mean state machine. 
  State machines are wonderful things for achieving simple, bug-free 
code, but they have a cost; they are implicitly single-threaded.  This 
can mean you cannot use them in some situations, because you will 
inherently block whenever you perform work.

Also note that with GetQueuedCompletionStatus(), you're supposed, for 
optimal performance, to have multiple threads (2xCPU) blocking on the 
IOCP object.

Given the advent and growing popularity of multi-core CPUs, single 
threaded blocking seems inappropriate.

Note though that with GetQueuedCompletionStatus(), the user has no 
synchronization work to do.  The API handles it all behind the scenes.