Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: Is a called package in thread storage?

by renodino (Curate)
on Jul 15, 2008 at 21:03 UTC ( #697803=note: print w/replies, xml ) Need Help??

in reply to Is a called package in thread storage?

(Note: The following applies to Perl threads only, not to system-level threads in general)

As near as I can decipher from your post, the lexicals are thread private.

Each Perl thread gets its own Perl interpretter. When a new thread is spawned, it gets a cloned version of the parent's Perl interpretter context (w/ some minor exceptions). Which means any lexicals in your package will simply get cloned, not shared, between the threads.

If you need to share variables between threads, you must explicitly declare them to be shared. See threads::shared.

Alas the only book I'm aware of that covers the subject is the Camel 3E, and its (a) quite dated and (b) not a very thorough discussion. There have been some articles on the subject, but I believe most of them are fairly dated at this time as well. I've not checked the latest editions of Learning or Mastering, so I don't know if they discuss ithreads.

Perl Contrarian & SQL fanboy
  • Comment on Re: Is a called package in thread storage?

Replies are listed 'Best First'.
Re^2: Is a called package in thread storage?
by Wiggins (Hermit) on Jul 16, 2008 at 14:23 UTC
    All of these have been great answers, to really understand what is really happening in the background! But it makes me pause and step back for a moment.

    I started in FORTRAN (without a number), then SNOBOl, ALGOL, PL/1, 'C', Pascal, C++, Java(ugh!), and now Perl (last 8 years). And the one constant to be found here is that each language attempted to "abstract away" some complexity from the language it is attempting to usurp. And in "dumbing down" or "abstracting" the understanding of the basic concepts, the programmer is required to understand less and less of the fundamental concepts.

    Just look at what the answer to my question has brought out. " use 'require' rather than 'use' in threads to control bloat"; that is something you would never find in a book, since it would require the reader to know too much about the underlying concepts, implementations and philosophies. And the implementation of Threads:shared hasn't even been touched. I really want a "thread shared Hash that is tied to a dbm', but I am settling for my own disk journaling system to recover from any "unplanned termination".

    And would many of the readers have the foundation in 'computer science' to understand memory management or the complexities of parameter passing or 'varargs' ( or how about 'varargs' on a risc processor, with no stack)? Yet, to solve the hard problems, the programmer must understand what lies beneath. Dive below the abstraction!

    I love Perl, and abstraction is great; but we should never forget how to program assembler in a linear address space!

    A real world example that may have lost $1,000,000

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://697803]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2020-10-01 13:36 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (13 votes). Check out past polls.