Re: 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 perl.com 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

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
http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx

[reply]


XP is just a number
	PerlMonks