Looks like Win32 "get sock name" can't be done by one thread (by which I mean "Win32 thread" not iThread) while another thread is in the middle of "accept" (on a different socket). It doesn't look like it is Perl locks that are causing the deadlock based on Perl's "accept" and "get sock name" being in the middle of calling Win32's "accept" and "get sock name" (respectively).

So the problem should go away if you replace emulated fork() with spawning, taking care to inherit the parent's file handle in the child. And this method works on Win32 (Apache uses it).

But in trying to quickly throw together the pieces needed to do this in Perl, I have my doubts that Perl can currently support it well (at least in the case of sockets and even more so when trying to use something like HTTP::Daemon).

So, rather than inherit a socket created in the parent, you might just spawn and create separate sockets in each process using

my $d= HTTP::Daemon->new( ... ReuseAddr=>1, ... );
[download]

I'm not certain that such "separate but equal" sockets will work as desired, but it seems worth trying.

"Spawn" in Win32 Perl can be spelled something like

system( 1, $^X, $0, @ARGV );
[download]

but probably add something to let the child know it is a child. For example, set some %ENV variable or add some extra argument to the child's command line.