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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > Guido: > > > > On 03/04/07, Guido van Rossum <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
