|Perl: the Markov chain saw|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
"thread safety" is a general property, not something to do with a specific implementation of Perl threads.
The implementation of Perl threads that you are commenting on is mostly like "forking, but without all of that efficiency", sort of the worst of both worlds (threading and forking). So my comment wasn't to do with how well you could make your stuff work with that implementation of threading.
And having your object be usable with a threaded Perl so long as you don't share your object(s) between threads just means that that Perl's threading implementation isn't completely broken, not that your object is thread safe.
Your method isn't thread safe because you can't have two threads using the same method from the same class at the same time on different objects -- where, again, I use the more common definition of "thread" here, that is, "two execution streams that share (almost) all of their virtual memory", not as in "two separate instances of Perl interpreters on related threads, one of which has laboriously and inefficiently made a near-complete copy of the other one".
But you are correct in that lack of thread safety isn't a horrid problem here, because Perl has yet to have a decent threading model.
BTW, when I released Data::Diver (just a few days ago), I used a "get last error reason" scheme despite the fact that it isn't thread safe. Normally my modules use objects, to avoid "global" problems such a thread safety and to support user configuration. This particular module didn't have any configurable bits to worry about and I felt using OO would have been much less convenient for most uses of the module. But that meant that my simple way of getting error details wasn't thread-safe. But I didn't want to complicate the important parts of the module to overcome this problem with less-important part of the module, especially since Perl doesn't really have good thread support anyway.
But I did notice that I was doing something that wasn't thread-safe. It also isn't re-entrant, which becomes a problem if multiple layers of your application use it. I think your use of localized globals for access to member data is re-entrant in the absense of threads, though.
So, upon reflection, given the current state of Perl, I guess I shouldn't have been surprised that you didn't mention nor worry too much about whether your Perl module was thread-safe (neither did I). Though I was also curious if my impression was correct.
In reply to Re^3: Outside-in objects with Object::LocalVars (threads)