Re: Keeping an INET socket inside a shared object

Have you tried turning off the CLOEXEC flag?

  use Fcntl;
  ...
  my $socket = new IO::Socket::INET(@_) or die;
  $socket->fcntl(F_SETFD, 0) or die; # clear CLOEXEC
  ...
#  $socket->fcntl(F_SETFD, FD_CLOEXEC); # set CLOEXEC
[download]

It's also probably a good idea to ->shutdown the sockets once you're done, especially if they may "leak" to some other thread or process.

ps. I've not the foggiest idea what serially bi-directional could mean. AFAIK streams are full-duplex, with separate receive and send queues, and usually have an out-of-band (OOB) mechanism too (e.g. telnet uses this to signal interrupt).

Comment on Re: Keeping an INET socket inside a shared object Download Code

Replies are listed 'Best First'.
Re^2: Keeping an INET socket inside a shared object by BrowserUk (Patriarch) on Jan 18, 2014 at 18:50 UTC
I've not the foggiest idea what serially bi-directional could mean. AFAIK ... Try it. Connect a socket to a server that attaches, and then tries to read from the client. Start a thread (in the client) that goes in to a read state on that handle. Then try to write something to the server via that handle from the main thread. The write will block indefinitely pending the completion of the read in the thread, which will never occur because the server won't send anything. 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". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^3: Keeping an INET socket inside a shared object by oiskuu (Hermit) on Jan 18, 2014 at 19:04 UTC
That's the blocking mechanism, and it's not limited to just sockets either. Multiple writes may block each other similarily. Set your fd nonblocking if this is a problem...	[reply]
Re^4: Keeping an INET socket inside a shared object by BrowserUk (Patriarch) on Jan 18, 2014 at 20:17 UTC
Set your fd nonblocking if this is a problem... And how do you think non-blocking works with threads? What happens if 2 threads issue a select against the same thread and a state transition occurs -- ie. the socket becomes readable or writable -- which thread responds? Answer: they both do. And what happens when they both try to read from or write to the same socket at the same time? In a single threaded app, a socket is only readable or only writable at any given moment. Being single-threaded means that the code can only ever try to do one thing or another at a time. Ie. serially bi-directional. In single threaded apps it doesn't matter. In multi-threaded apps it does. 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". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]