On Wed, Mar 07, 2007 at 12:44:45PM -0000, Toby Douglass wrote: > > On 3/7/07, Toby Douglass <toby.douglass@xxxxxxxxxxxxxx> wrote: > >> I've written a C10K solution for Windows, libiocp. > >> ... > >> It is useful in its current form? > > > > this is useful for libevent. unfortunately i am not volunteering a patch > > :) > > They know about it. I've removed them from the CC:. The problem is that > the way libiocp is written is, as I understand it, not particularly > compatable with the way libevent is written. Merging the two is not an > obvious proposition. How focused is the Tor code on libevent? is it only > used for sockets? Tor uses Libevent sockets, signals, DNS, and the occasional timer. The right thing to do when you need to support multiple IO frameworks is usually to think of some abstraction that works with all of them, implement that abstraction with all of them, and then write your other code to use that abstraction. To get IOCP used by Tor, the first step is to find some abstraction that both IOCP and libevent can provide, and then get Tor to use that abstraction for its network operations. Right now, Tor uses libevent for networking stuff mainly for notification of which sockets are readable and writable. It seems like IOCP is better at determining when reads and writes are done. If this is the case, it seems way easier to use the event_base-based functions in libevent to implement something like IOCP's interface than to use IOCP to implement something like the event_base functions. In fact, there's already a good candidate: IOCP looks like a closer fit for libevent's bufferevent interface than for its regular event_base interface. (Bufferevent is currently written to assume it's working using an existing event_base, but there's nothing stopping somebody from putting a parallel implementation into place.) If we can get better windows performance by using bufferevent, I bet that would be the cleanest way to go about this. Of course, this wouldn't be trivial work on Tor's side, and we might need to extend the bufferevent interface to make it do what we need. Still, this feels like the way forward to me. yrs, -- Nick Mathewson
Attachment:
pgpJCXTdDeA6U.pgp
Description: PGP signature