|more useful options|
Re: Sharing globsby renodino (Curate)
|on Nov 02, 2007 at 00:49 UTC||Need Help??|
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