This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients exarkun, giampaolo.rodola, janssen, pitrou
Date 2010-04-26.21:47:51
SpamBayes Score 1.0105688e-05
Marked as misclassified No
Message-id <1272318602.3436.10.camel@localhost>
In-reply-to <>
> Well, at the risk of stating the obvious, perhaps the dup() thing
> should be eliminated.  The justification for it seems less than clear,
> and apparently it causes some problems.

I've just found another problem while investigating the cause of some
sporadic Windows failures:

I've reproduced it on an XP VM and the explanation is that, sometimes,
just after a dup() of a socket, calling getpeername() on the child
socket fails (while getpeername() on the parent succeeds). It seems very
timing-sensitive: if I insert enough code after the dup(), the call to
getpeername() succeeds.

I will fix the buildbot issue by using a different logic (simply, call
getpeername() on the parent rather than the child), but this seems to
confirms that dup() may not be a good idea.
Date User Action Args
2010-04-26 21:47:53pitrousetrecipients: + pitrou, exarkun, janssen, giampaolo.rodola
2010-04-26 21:47:52pitroulinkissue8524 messages
2010-04-26 21:47:51pitroucreate