[Libevent-users] Add support for WINDOWS Overlapped IO

[Zhu Han]

>
> > 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.



I have made some mistake when I type the above words. I just mean you should
issue socket_internal_iocp_read firstly and then let the callbacks to
consume the data. However, in your code, you invoke the callbacks before
socket_internal_iocp_read. See the  following snippet:
      siss->callback_function( siss->socket,
SOCKET_IOCP_SOCKET_RECV_SUCCESS, siss->read_buffer, byte_count, (void *)
siss->user_state );
      socket_internal_iocp_read( siss );


> 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.


As others have pointed out,  Async WRITE is important for high-performance
server.

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.


Single-thread event-driven model just means the event loop is running in one
thread's context. There a lot of ways to combine it with the multi-thread
worker.

_______________________________________________
> Libevent-users mailing list
> Libevent-users at monkey.org
> http://monkey.org/mailman/listinfo/libevent-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://monkeymail.org/archives/libevent-users/attachments/20061211/675a257b/attachment.htm