I haven't found any good mechanism for sharing IO::Socket::INET objects between threads.

(I'm the guy that 'discovered' the fileno trick for sharing file handles; so I know a little about this. :)

And, FTR, I am of the opinion that designing architectures that requires or uses shared objects is fundamentally flawed.

This is doubly true if those shared objects encapsulate process-global entities like sockets, filehandles, directory handles etc.

Think about this:

1. if 2 or 3 threads have access to a shared tcp socket; which one listens?
2. And if one thread wants to send something, it can't do so if another thread is reading -- waiting for input.

Whilst sockets are bi-directional, they are serially bi-directional, which is to say they can only be communicating in one direction at any given time.

With a single thread handling a socket, it is easy to manage that it send something, then reads the reply, sends something, then reads the reply. (Or waits for input then responds...)

But coordinating between multiple threads becomes fraught with opportunities for deadlocks and infinite blocks.

In short, a shared object architecture makes no sense when dealing with sockets.

The correct alternatives are:

• have a thread that manages the socket and other threads send requests to/receive responses from that thread. This assumes the application is a multi-threaded client talking to a remote tcp server.
• If the application is a multi-threaded server, then the main thread monitors the listening thread and each new client gets it own dedicated thread.