Bug 629097 describes a thread race involving 
asyncore.pool(), and was closed with "so don't do that".

Polling exception sets is new in 2.4, though, and opens 
the same race to formerly safe uses:  leaving 
indeterminate junk in the socket map, provided that junk 
doesn't call itself readable or writable.  Such junk never 
got passed to select() before 2.4, but always gets 
passed to select() in 2.4.  This is incompatible behavior, 
albeit in a grey area.

More discussion starting at

http://mail.python.org/pipermail/python-dev/2004-
August/047817.html

Logged In: YES 
user_id=11375

The attached patch restores the behaviour that fds are only
checked if they're readable or writable.  However, even with
the patch the ZODB/ZEO tests still fail for me.

Logged In: YES 
user_id=31435

No patched is attached (you have to check the box, etc).

I was running Zope3 tests, and testManyClients specifically is 
what fails now (plus some irrelvant failures caused by the 
testManyClients failure).  testManyClients isn't a ZODB/ZEO 
test, BTW.  I didn't see any failures in ZODB/ZEO tests due 
to the asyncore change.

Logged In: YES 
user_id=11375

Attaching patch.

Logged In: YES 
user_id=31435

Logic similar to the logic in the patch worked for me when I 
tried it.  Suggest it would be faster and clearer to just add

    e = r + w

to the 2.3 asyncore poll().

Logged In: YES 
user_id=11375

'e = r+w' means 'e' can contain the same descriptor twice, 
if it's both readable and writable, and I think this
matters.  Duplicate fd's don't cause a problem with the
select() system call itself, but the return value from
select.select() would include the file descriptor twice. 
(I've attached a test program that demonstrates this for
readable fds.)  

Therefore, I think the 'if is_r or is_w' logic is necessary.

Logged In: YES 
user_id=11375

Original patch committed as rev. 1.61 of asyncore.py.  I'm
leaving the bug open until Tim (or someone) reports that the
problem is fixed.

poll2 (the one that uses select.poll()) should automatically
remove objects for which POLLNVAL is set -- that's what the
error means, after all.  I'll worry about that after
2.3alpha3 is released.

Logged In: YES 
user_id=31435

Zope3's problem w/ asyncore appears to be fixed.  Thanks!

WRT

> Therefore, I think the 'if is_r or is_w' logic is necessary.

I expect you're right.  I think I had vaguely in mind that "the 
usual" implementation of fdsets represents them as bit 
vectors, so that redundancy wouldn't hurt.  But that's not 
the only part of the story, and I overlooked that.

Logged In: YES 
user_id=80475

Tim, can this be marked as fixed and closed?

Logged In: YES 
user_id=31435

Yup, this is fixed as far as I'm concerned, so closing it.