develooper Front page | perl.ithreads | Postings from April 2008

Re: Perl threads under Windows

Thread Previous | Thread Next
From:
Dean Arnold
Date:
April 20, 2008 08:32
Subject:
Re: Perl threads under Windows
Message ID:
480B61F4.4000001@presicient.com
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About