FWIW, I've checked a fix into the trunk. The code was waiting half a second and assumign that the server thread was ready. This occasionally failed of course. I fixed it by using an event variable instead of a sleep call. Not sure if it's worth backporting, as it is only a race condition in the unit test. (But I also don't see anything wrong with a backport. :) --Guido On 4/3/07, Guido van Rossum <guido at python.org> wrote: > I'm not sure I agree with your analysis -- the test that fails is > using unix domain sockets, not TCP. > > On 4/3/07, Hasan Diwan <hasan.diwan at gmail.com> wrote: > > Guido: > > > > On 03/04/07, Guido van Rossum <guido at python.org> wrote: > > > But I saw this failure during a regular regrtest run as well. How > > > would you suggest to fix this?i > > > > > > > You'll need to make the connect/close lines into a critical section and have > > execution suspended for the TCP wait time. It defaults to 60 seconds on BSD > > sockets, but I'm not aware of the constant for it (a quick survey of the > > header files doesn't show anything promising). On the other hand, I don't > > think you're going to be running this particular test a number of times > > quickly (or will you?). In the final examination, I suspect it's a race > > condition. > > -- > > Cheers, > > > > Hasan Diwan <hasan.diwan at gmail.com> > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4