Re^3: is a readonly hash thread safe ?

Even that reference is just a copy. See perlthrtut and/or threads::shared. Perl ithreads are based off the idea of the Win32 fork emulation, which is why every thread gets its own copy of (almost) everything. This likely is the only possible implementation anyway without risking lots of locks like Python has with its much maligned Global Interpreter Lock, as even reading a Perl variable means writing to shared memory (the refcount or integer slots for example) otherwise.

Comment on Re^3: is a readonly hash thread safe ?

Replies are listed 'Best First'.
Re^4: is a readonly hash thread safe ? by gulden (Monk) on Jul 15, 2009 at 11:12 UTC
Perl has also serious problems with LOCKs, using a simple REGEX in several thread instances of the same program causes LOCKs to go HIGH. And this is valid not only for REGEX's. See node	[reply]
Re^5: is a readonly hash thread safe ? by Anonymous Monk on Jul 15, 2009 at 11:22 UTC
tell it to perl5-porters, please :)	[reply]
Re^4: is a readonly hash thread safe ? by cbrauner (Novice) on Jul 15, 2009 at 12:37 UTC
i pass a hash-reference to the thread, so the thread gets (a copy of) the reference - BUT the data referenced by the hash-reference should be only once in memory ?	[reply]
Re^5: is a readonly hash thread safe ? by Corion (Patriarch) on Jul 15, 2009 at 12:48 UTC
No. The reference is a copy of the reference, and the data is a copy of the referenced data. Again, see perlthrtut, and threads::shared. Threads don't share things as you might come to expect if you think of C-level threads.	[reply]