Serves me right for yakking before thinking...

I just realized the Big Issue with installing the handle context in the shared interpretter, and once again its the beached whale.

Since any access to a shared variable might cause interpretter state changes, and (presumably) accesses to a handle might cause even more state changes than just touching a scalar, the shared interpretter lock would have to be held for the duration of access to the handle...including during the I/O operations applied to said handle. Which means that every other thread that needs to do something to any shared variable - no matter how trivial - has to wait for some other thread's I/O operation to complete. Which might be a very long time...

Which essentially means the handle can't be used from the shared interpretter (at least, not for anything more than bookkeeping purposes).

Which leads me back to the PerlIO layer idea. If a shared scalar were associated with each handle, the handles might be treated as regular atoms (string/number literals) when passed between threads. The receiving thread would then need to instantiate the handle's context in its own private interpretter context. Which is just a fancier way of doing what we've already been doing, i.e., passing the fileno and re-opening in the recving thread. Of course, the semantics of file operations get a bit confused at that point: passing a handle from Thread A to Thread B, wherein Thread B does a seek and lets Thread A know its repositioned the file pointer, leaves Thread A stuck at the old file position, since Thread B has a distinctly new handle. Not an issue for stream handles, but block I/O can get confused.

And then there's the need to collect all the other layer info to re-instantiate the handle, which won't exist until 5.10 (maybe 5.8.9 ?)

So ideally, the resuscitation of the handle in the receiving thread would actually perform a clone operation, rather than a re-open. But then things get hairy wrt refcounts. (Thread B's handle reference goes out of scope, so the private interpretter invokes close() on it...and suddenly Thread A starts getting nasty errors when it tries to use the handle).

In summary: its complicated.

Perl Contrarian & SQL fanboy

In reply to Re: Sharing globs by renodino
in thread Sharing globs by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.