I've almost finished code to handle arbitrary numbers of sockets under Win32 using WaitForMultipleObjects(). I expected to complete with one more weekend of work and then move to test.
I've written the code from scratch last weekend. There's a socket object, a listen thread object and a listen thread manager object. The exposed API is that of the listen thread manager and consists of four functions; new() delete() // this is for the listen thread manager object add_socket() remove_socket() Each socket has an associated callback function which is called when data arrives. Each listen thread handles up to 61 sockets (three objects are used internally). The listen thread manager load balances sockets between threads as necessary, deleting excess threads. The listen threads re-order their socket lists on every read, so that the interrupting socket is moved to the end of the their list of objects. This is because the list is examined in-order by WaitForMultipleObjects(), so rapidly firing objects can mask objects further down the list. There exists some investigation which indicates that there is a limit of about 4k sockets for Windows, due to the necessity of allocating a certain amount of non-paged pool per socket combined with a hard limit on the amount of non-paged pool. This equates to about 65 threads of 61 sockets. A question is whether it's better to fire up all these threads at init, and forget about load balancing. Bear in mind the fact that WaitForMultipleObjects() reads it handle list in-order. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
