I'm just starting to evaluate Twisted, so apologies if these questions seem naive. It seems to me that the Twisted model for 'reactor' is actually not what you'd expect from the name (at least, if you have a background in other reactor implementations including ACE, basic select etc and Java NIO) since it a) handles queueing outgoing data for you and b) presents incoming data after completion of the IO So its a model that maps well to an AIO implementation so long as inputs from non-blocking sources complete as soon as "some" data is ready, rather than buffer full. This high level approachh should work well on Windows - which is really pleasing. (Albeit there may be buffer starvation issues on all platforms I guess, but that's probably scaled beyond Python ambitions) A quick look at the open bug list shows a lot of noise on the Win32 side though. Is there any reason to have any framework that calls the Win32 select function? And why is the event reactor broken at 64 handles? From what I can see, that's not how to use WaitForMultipleEvents - rather one should regard it as a way to hash completion events from standard overlapped IO requests against 61 of the handles and keep a list of the IOs in progress against each handle. Scales admirably, unlike any attempt to treat the handle array like a select fd_set. Shouldn't broken Win32 implementations be 'retired'? Also - is there any way to determine how much data is queued for write against an ITransport? It appears not, though I would have thought it useful (and, a way to get an event callback when the queued amount falls below a specified threshold) - then in cases where data can be generated on demand we can limit the outgoing buffer usage. James