In that case you need to look at the several things in the glob (a scalar, a hash, an array, a file handle, maybe a few other more exotic things but unlikely) and see which are being used by the object. Share each of those and then, in each thread, build a new glob and put the shared things into it (and then bless the result).

I've tried this in the past -- for IO::Socket objects amongst others -- and despite many attempts over several years; never succeeded in getting it to work.

Maybe it would be easier with a telnet object, or maybe not; but either way, as there is no possibility of a remote telnet server allowing multiple concurrent transactions via a single session, there is simply no point in pursuing it.

Far better -- simpler, more reliable, safer -- to either:

1. Serialise the multiple streams through a fourth thread that using a single non-shared session.
2. Or: have each thread create its own non-shared telnet session and let the remote telnet server take care of multiplexing those sessions.

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).

- tye        

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

Share? Maybe I can help.

---

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 knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!