Octavian Rasnita wrote:
I understand that the perl threads (at least under Windows) are actually a kind of separate processes that don't share the memory unlike the Windows native threads, and that's why they are not so slim as the Windows threads and why they can't share objects.
Yes and no. ithreads creates a new Perl interpretter in each new thread, and "clones" the context of the parent thread into the new interpretter (in order to emulate a UNIX fork() operation in the Windows environment). The ithreads architecture applies to all platforms, not just Windows (as of Perl 5.6). While data cannot be directly shared between each interpretter context (and therefore, each thread), the threads::shared module provides a tie'ed interface to another shared interpretter context such that all the thread-private interpretters can access the variables defined within the shared interpretter. Unfortunately, the implementation suffers from significant lock contention (access to the shared interpretter requires a global lock), and some limitations (e.g., no shared closures, no shared file handles). Objects *can* be shared, assuming you follow the guidelines specified in the threads::shared documentation (especially the section titled "OBJECTS"). However, keep in mind the previously mentioned global locking issues when creating such objects. If you create a hash-based object, and then frequently reference member fields of the hash, you could suffer serious performance issues. HTH, Dean Arnold
