in reply to How do you share an object(Telnet Session) between threads?

If you had 3 non-Perl threads, then you could share your Net::Telnet object between the threads so long as only one thread was allowed to access it at a time. Three Perl threads means 3 separate instances of the Perl interpreter. Which means sharing between them involves making 3 copies of every piece of the object. threads::shared knows how to do that for simple data. It can't just do it automatically for you in the case of things containing file handles.

You should be able to work around this limitation if you do your own locking to prevent simultaneous access and take steps to prevent problems from multiple copies each trying to tear down the file handle... if the module doesn't leak state outside of the object. For example, using buffered I/O would leak information into the per-interpreter buffer. Or storing some state information in an (unshared) class-global structure would be a problem.

So, you'd have to inspect the guts of the object to figure out where the file handle is stored. Remove the file handle before calling shared_clone(). Share the fileno of that handle. In each thread, put a clone of the file handle back via something like: 

    open my $clone, '+<&=', $fileno or die ...;

[download]

- tye        

  • Comment on Re: How do you share an object(Telnet Session) between threads? (clone handle)
  • Download Code

Replies are listed 'Best First'.
Re^2: How do you share an object(Telnet Session) between threads? (clone handle)
by jmlynesjr (Deacon) on Sep 29, 2015 at 19:26 UTC

    Tye, I don't think the locking will be an issue. The shared flags seem to be working fine. I don't currently have the internals knowledge to implement your suggestion. I found a BrowserUK reply concerning sharing file handles between threads. How do I get the filehandle out of the Telnet object? When I print Dumper $telnetsession, I get,

    $VAR1 = bless( \*Symbol::GEN0, 'Net::Telnet');

    I would be nice to figure this out and get it documented

    Thanks for your response.

    James

    There's never enough time to do it right, but always enough time to do it over...

[reply]
[d/l]
[select]

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

      - tye        

[reply]
        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.
        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!
[reply]

In Section Seekers of Perl Wisdom