Oh, I agree with most of what you say. And I'm not surprised that it (at least) often doesn't work. There are plenty of things that can make it go wrong (as I noted). (Hell, I have several experiences of trying to get things to work via Perl threads w/o even trying to share file handles and not being able to get it to work. ;)

But I was not proposing even multiple transactions much less concurrent transactions. It seemed clear to me that what was desired was access to a single session from multiple threads but not concurrently (and that impression is enforced by subsequent comments).

You can have multiple Perl handles to the same file descriptor. And you can arrange for the object state outside of that file handle to be copied to other threads via threads::shared. So, thread X does some operations, E, with the telnet session. That causes some data to be written to or read from the socket and for the state of the object to be changed. Later, some operations, F, are desired. If they happened to be done by thread X, then, of course, they work fine. But (with many caveats), thread Y should also be able to attempt F and it will get an updated copy of the object state and then interact with the same socket file descriptor but via a different Perl file handle and the remote system will see no difference compared to what thread X would have done.

But it is indeed better to arrange for only one thread to have need of the telnet session. I am certainly not advocating against that. I was lazy for not being explicit that the approach I described should be a last resort. I kinda thought that such was not hard to realize, but being clearer would have been better.

I wish I had time to actually try this out and diagnose the types of problems I run into. I'd be surprised if I didn't run into any. Digging into the specifics would be interesting (and often educational).