On Sat, Apr 9, 2011 at 4:43 AM, Pavel Pergamenshchik <pperg...@gmail.com> wrote: > On Fri, Apr 8, 2011 at 6:26 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> > wrote: >> >> On Apr 8, 2011, at 2:56 AM, Tristan Seligmann wrote: >> >>> On Fri, Apr 8, 2011 at 4:52 AM, Kevin Horn <kevin.h...@gmail.com> wrote: >>>> Note that you can wait on more than 64 objects at a time, just not using a >>>> single WaitForMultipleObjects call. The MSDN page Glyph pointed out has a >>>> little more info. >>> >>> The proposed solutions, however, seem rather unsatisfactory. If you're >>> going to start spawning new threads to monitor everything, you might >>> as well just do IOCP in another thread, or even in the main thread (at >>> least as far as I know). >> >> I think we may be close to the point where we can drop win32eventreactor >> completely. I think IOCP can deal with arbitrary Windows events too, so if >> we just expose that in a compatible way, and whatever else comes along with >> it, we can just delete win32er without losing any functionality. (Or maybe >> we already do? Not my area of expertise any more :)). > > It's technically possible, but it's not a thing that iocpreactor > currently does. Someone (hurr hurr) needs to stop slacking and > implement it, along with support for waiting on an arbitrary number of > handles.
I've found a "tutorial" by Richard Tew. http://posted-stuff.blogspot.com/2009/07/iocp-based-sockets-with-ctypes-in_31.html There is a lot of stuff to read. I can figure out if: 1. IOCP doesn't give a 100% CPU load when idle 2. It is doesn't seem like it is possible to listen to console events like WFMO, but I didn't try > Also, how much do we care that win32er can be used without a compiler, > but iocpreactor needs one to build the API wrapper? -- anatoly t. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python