Granted, at first I thought it was a global lock, but it appears to be much finer grained than that. Perl's accept will not block all stat operations, just those on the socket passed to accept

Which is where I was coming from. If PerlIO didn't use fstat() to try to determine if a file descriptor belongs to a "regular" file--which is a pretty expensive way of doing it, even if it worked--then that paricular problem would go away.

Similarly for the ftell() which isn't useful on a socket. All of this takes place as a part of PerlIO_dup() when they are cloning. I don't understand why they can't just use the CRT dup() or dup2()?

The lock appears to be specific to a handle or descriptor.

That's partly why I reached the conclusion that it must be in the windows CRT. Why would they lock them for windows and not *nix?

And tracing backward from Win32sck.c:Win32_accept(), darned if I can see anywhere locking is applied. But once you get into PerlIO.c, there are so many layers of macro and indirection through any one of a dozen different flavours of IO layer dispatch tables, I can quite see that I might have missed something. I don't think I did, but I might have.

I would start by finding out which, then finding out where the lock is stored in the relevant structure, then find out what uses the lock.

At this point: be my guest :) I'm done. (For a few days at least.)