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

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...

Replies are listed 'Best First'.
Re^8: threads + sockets stalling question
by BrowserUk (Patriarch) on Mar 17, 2010 at 17:32 UTC
    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.

      [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";

        The problem does not lie in the CRT. This does everything that my sample in the OP and your sample do, using the CRT directly, and there are no signs of any locking:

        Output:

        C:\test>828831.exe 828831.c(115):_fstat( lsn, &s ) == -1 failed with error 9 (Bad file descriptor) 828831.c(116):_tell( lsn ) failed with error 9 (Bad file descriptor) 828831.c(117):_dup( lsn ) == -1 failed with error 9 (Bad file descriptor) Connect from: 120 Thread started for client 120 Connect from: 128 Thread started for client 128 Thread completed 4895 echos for client 128 Thread completed 11575 echos for client 120

        The locking is occuring within Perl itself, but damned if I can work out where. It must be in Win32 specific code given that other OSs aren't suffering the same problem. But given that OS conditional code is spread throughout the entire code base, it'll take someone clever than me to find it.


        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.