|Do you know where your variables are?|
Hmmm. That's a big drawback. I'm really not very thread-savvy, so it's not something that was top of mind. Can you help me understand what about it makes it thread-unsafe? My limited understanding of threads was that all data is copied unless explicitly shared -- which I suppose, on reflection, does make me think that using the refaddr of the object as a key to the data is likely a problem when the blessed reference gets cloned into the new thread. (If that's true, I assume that problem affects inside-out objects, as well, then?) Maybe it makes sense to generate a unique ID for each object and store it in a blessed scalar used as the underlying object.
What other things do I need to consider?
Update: After some reading of perlthrtut, threads, threads::shared, Things you need to know before programming Perl ithreads, and Where Wizards Fear to Tread (perl.com), I'm not sure this is a "big" drawback. From what I can tell, the major problem is that the object ID gets lost across the creation of a new thread; that can be fixed by embedding a unique ID as described above. After spawning a thread, each thread is "safe" in that they won't interfere with each other, but it means that changes to object 1 in thread A don't appear in the corresponding object 1 in thread B -- but that's by design in the perl threads approach. To be able to share across the boundary should be theoretically possible by marking the package globals holding data as shared and implementing appropriate locking/semaphores. That complexity would appear to be present in any object framework that tries to synchronize an object across thread boundaries, not just this one. Still, I'll back-burner the idea of implementing a thread-safe version of this somewhere down the line -- at least the safe-across-a-spawn safe, and maybe beyond.
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
In reply to Re^2: Outside-in objects with Object::LocalVars (threads)