Front page | perl.perl5.porters |
Postings from June 2013
On Thu, Jun 27, 2013 at 04:34:17PM -0700, bulk88 via RT wrote: > On Mon May 20 02:10:13 2013, tonyc wrote: > > > > I see this failure maybe 1 in 20 runs (Windows 7 x64, Core i7). > > > > I suspect the problem is that winsock is invalidating the accept socket > > once the child socket goes out of scope, causing a race in the accept() > > implementation. > > > > I changes the code so the child reads a line from the socket, and > > the parent closes the socket. With that I had 2700 successful runs > > before I stopped testing. > > > > I'll try a smoke-me to see if it breaks anywhere else. > > > > Tony > > Any updates TonyC? It smoked ok, but I don't trust that it fixes the underlying problem (which may not be fixable, leaving us with the work-around.) My theory above, as written, is hopefully nonsense - Windows returning a socket and suddenly making it not-a-socket, rather than return an end-of-file or EPIPE on the next operation would be even more broken than I expect from Microsoft. For a Real™ fork() any open file handles or sockets are cloned in the child - the child can exit or explicitly cose their socket handle, but it won't have an effect on the socket handle the parent has. Under Win32 we emulate that, which I suspect is the real cause of the problem here - when a thread is created fp_dup() calls PerlIO_fdupopen() which does reasonable things on Unix, but on Win32 that leaves all the work to win32_fdupopen(). win32_fdupopen() calls win32_dup() a trivial wrapper around dup() - and I don't see how that works for a socket fd unless the CRT dup() is tolerant of errors from DuplicateHandle(). TonyThread Previous | Thread Next