develooper Front page | perl.perl5.porters | Postings from August 2013

[perl #118059] race condition+fail in dist\IO\t\cachepropagate-tcp.t

Thread Next
From:
Tony Cook via RT
Date:
August 27, 2013 23:41
Subject:
[perl #118059] race condition+fail in dist\IO\t\cachepropagate-tcp.t
Message ID:
rt-3.6.HEAD-1873-1377646871-429.118059-15-0@perl.org
On Thu Jun 27 23:50:22 2013, tonyc wrote:
> 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().

This theory turned out to be nonsense, I'm exploring the behaviour some
more.

Tony

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=118059

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About