in reply to Re^4: [threads] Sharing object through threads
in thread [threads] Sharing object through threads

True, but who cares. He has a freshly accepted socket, so all he needs is
sub new_inet_from_fd { my ($fd, %arg) = @_; my $timeout = delete $arg{Timeout}; my $blocking = exists $arg{Blocking} ? delete $arg{Blocking} : 1; my $sock = IO::Socket::INET->IO::Handle::new_from_fd($fd, '+<'); ${*$sock}{'io_socket_timeout'} = $timeout; ${*$sock}{io_sock_nonblocking} = !$blocking; $sock->blocking($blocking); $sock->autoflush(1); return $sock; }

It produces a socket whose operations don't timeout (unless one is specified), whose operations do block (unless otherwise specified), and that does autoflush. Everything in IO::Handle other than autoflush is at its default.

Replies are listed 'Best First'.
Re^6: [threads] Sharing object through threads
by BrowserUk (Patriarch) on Nov 17, 2009 at 22:22 UTC

    I'm not sure where you get all the stuff about blocking and timeouts from? It doesn't appear to be derived from anything the OP posted.

    If he is only ever going to need simple IO::Sockets, he might get away with it, but if he needs any of the stuff that layers atop IO::Socket, he'll find the limitations for sure.


    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.

      [the stuff about blocking and timeouts] doesn't appear to be derived from anything the OP posted.

      Why would I base a socket constructor on code that doesn't contruct sockets?

      but if he needs any of the stuff that layers atop IO::Socket, he'll find the limitations for sure.

      Why do you say that? It's was made for IO::Socket::INET. It should work with IO::Socket::INET clients and servers.

      Incidentally, it should also work with IO::Socket::UNIX clients and servers buy simply changing the package name on the 6th line.