in reply to Re^5: threads + sockets stalling question
in thread threads + sockets stalling question

the real problem is not that fstat and ftell lock the CRT

I agree with that, but rather than pointing the finger at accept(), (which (assumption!) locks the underlying file descriptor as it will be modified by when the call completes), but rather at the PerlIO that calls f*() calls on sockets.

I guess you could also blame the CRT for locking the file descriptors before checking whether they are valid handles for the operation to be performed.

Is it possible to recode accept to avoid the CRT?

On a cursory inspection I don't think so. accept() is just redined as win32_accept(), and that essentially just calls the CRT accept(): 

SOCKET
win32_accept(SOCKET s, struct sockaddr *addr, int *addrlen)
{
    SOCKET r;

    SOCKET_TEST((r = accept(TO_SOCKET(s), addr, addrlen)), INVALID_SOC
+KET);
    return OPEN_SOCKET(r);
}

[download]

I don't have access to the MSCRT sources, (I think you can pay for such access?), but from my point of view it's an opaque box. And probably should be.

In the end, like so many others, the root of this problem lies in the difficulty of trying to make a non-POSIX OS act like POSIX. It's amazing that as much works as does.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"I'd rather go naked than blow up my ass"

Replies are listed 'Best First'.
Re^7: threads + sockets stalling question
by Corion (Patriarch) on Mar 17, 2010 at 17:10 UTC

    Personally, I would assume that the VC CRT then calls the appropriate Winsock functions, which would be accept as imported from winsock.h. Maybe looking at whatever CRT/call sequence mingw uses could help, even if it moves Perl towards bringing its own OS to the table...

[reply]
[d/l]
[select]
      Maybe looking at whatever CRT/call sequence mingw uses could help,

      They almost certainly call accept(), which is probably what is being called now.

      But I don't think changing the accept() call is the right way to address problems in PerlIO. The former currently works, it's the latter that has problems.

      even if it moves Perl towards bringing its own OS to the table

      Perl already has far too many layers, one atop the other. Each added by a different person with a different agenda, and all intermingling in a way that is a nightmare to unravel. They never seem to throw anything away, just gloss over with a shiny new coat of code. Adding more layers isn't the right approach.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        [accept()] currently works, it's [PerlIO] that has problems.

        I don't see how PerlIO can be a problem. It's a system to provide IO layers to handles. Individual functions in Perl's IO library might have bugs, but that doesn't mean PerlIO is a problem.

        In fact, this replicates the problem outside of PerlIO (I think): 

        #! perl -lw
use strict;
use threads;
use IO::Socket;

my $lsn = new IO::Socket::INET(
    Listen => 5, LocalPort => '12345'
) or die "Failed to open listening port: $!\n";

async{
    print 'accept starting';
    my $c = $lsn->accept;
    print 'accept returned';
}->detach;

sleep 2;

print "-d starting";
-d $lsn;    # Freezes
print "-d returned";

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom