Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Can I/O operations on the same IO::Socket be executed in different threads?

by ikegami (Patriarch)
on May 12, 2015 at 15:12 UTC ( [id://1126432]=note: print w/replies, xml ) Need Help??


in reply to Can I/O operations on the same IO::Socket be executed in different threads?

If the only thing you do with the IO::Socket::INET and read and write from it, you won't have any problem since the object is not used at all for that (just the file handle on which its built).

use strict; use warnings; use threads; use IO::Socket::INET qw( ); use constant SHUT_WR => 1; my $sock = IO::Socket::INET->new( Proto => 'tcp', PeerAddr => $ARGV[0] // 'localhost:echo', ) or die $!; async { print while <$sock>; }; async { print($sock "abc\n"); sleep(3); print($sock "def\n"); shutdown($sock, SHUT_WR); }; $_->join for threads->list;

I don't know for IO::Socket::SSL.


Update: Added default argument.

Replies are listed 'Best First'.
Re^2: Can I/O operations on the same IO::Socket be executed in different threads?
by BrowserUk (Patriarch) on May 12, 2015 at 17:45 UTC

    How laughably naive of you to produce code that does nothing useful and announce: "you won't have any problem".

    No wonder p5p decided to "discourage" threads when "experts" go around handing out advice like that!


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
      Threads aren't discouraged by p5p. The docs mispeak. It's meant to be a warning on the heavyness of Perl threads. It's already in the process of being fixed.

        Threads aren't discouraged by p5p. The docs mispeak. It's meant to be a warning on the heavyness of Perl threads. It's already in the process of being fixed.

        Still not fixed 2020-12-02

Re^2: Can I/O operations on the same IO::Socket be executed in different threads?
by Anonymous Monk on May 13, 2015 at 02:12 UTC

    That junk dies with  Invalid argument at - line 2

    Or if you go and fix it and specify  'localhost:6666' it dies with No connection could be made because the target machine actively refused it.

    Windows doesn't have Unix domain socket, if thats what your program is supposed to use

    Very poor showing for such a super hyper pedant

      Sounds like you didn't actually run a server at localhost:6666? A simple echo server would do. (You can find one at localhost:echo sometimes, though it's trivial to write one.)


      IO::Socket::INET->new creates a TCP socket, not a unix socket.

        Sounds like you didn't actually run a server at localhost:6666? A simple echo server would do. (You can find one at localhost:echo sometimes, though it's trivial to write one.)

        Why would I need an external server to communicate between two threads using sockets?

        Does not compute

Re^2: Can I/O operations on the same IO::Socket be executed in different threads?
by sundialsvc4 (Abbot) on May 12, 2015 at 21:25 UTC

    I, too, don’t think that I fully understand the basis from which you speak, and I candidly suspect that your example might produce a “false positive” since it waits three seconds.   Thus, it is probably not a representative example of what might go wrong, since in your example it is unlikely that the threads would ever the threads would never actually conflict with one another.

    When you’re dealing with a real-world remote system, the status of that system is only represented by the single stream of messages that the system is sending-out on each of its sockets.   I think that, therefore, you need to have one thread on your end which is responsible for knowing the status of every one of them.   And, because socket-operations are not terribly fast, a select() loop works perfectly.   One thread, processing “one message at a time” from all sources at once, can always keep up and will never present a bottleneck.

    This venerable strategy elegantly avoids all timing problems.   One thread can easily accommodate all of the connections, and can (centrally) keep track of the status of all of them, so that all of the clients get exactly what they need and want:   “Please send this message to somebody, and give me the reply as soon as you get it.”   Due to the realities of network-I/O (and, remote systems ...), there’s no reason to make things any more complicated, and, as it were, plenty of reasons not to.

      I, too, don’t think that I fully understand the basis from which you speak,

      I figured I'd actually answer the OP's question. You see, the OP asked if one thread could read from a socket while another writes to the same socket.

      BrowserUk's incredible hostility is completely unwarranted. There are common applications for what the OP asks. Tunnels, for one. Another would be to avoid using select+ioctl to do non-blocking output (which probably doesn't work on Windows). I think IPC::Run does exactly this in some circumstances.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1126432]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (6)
As of 2024-03-28 22:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found