<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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.</blockquote><div> 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 ); </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > 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. </blockquote><div> As others have pointed out,  Async WRITE is important for high-performance server. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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. </blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> _______________________________________________ Libevent-users mailing list <a href="mailto:Libevent-users@monkey.org">Libevent-users@monkey.org</a> <a href="http://monkey.org/mailman/listinfo/libevent-users">http://monkey.org/mailman/listinfo/libevent-users </a> </blockquote></div>