[Twisted-Python] WaitForMultipleObjects socket limitation

anatoly techtonik techtonik at gmail.com
Sat Apr 9 03:26:06 EDT 2011


On Sat, Apr 9, 2011 at 4:43 AM, Pavel Pergamenshchik <ppergame at gmail.com> wrote:
> On Fri, Apr 8, 2011 at 6:26 PM, Glyph Lefkowitz <glyph at 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.horn at 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.



More information about the Twisted-Python mailing list