APerl is no different,

Actually, Perl's threads are very different from your description.

And, copy on write has almost zero benefit in perl scripts, because almost every access to every scalar (and every other internals data structure based upon them) is a write access. Either the reference count is incremented or decremented; or the status bits are changed; or a number is referenced in a string context and the SV field is written, or vice versa; or strings are encoded or decoded.

Each and every change, even the setting or clearing of a single bit (IV_OK etc.) causes the entire 4kb it is located in to be allocated to the new process and duplicated. CoW buys Perl almost nothing.

The bottom line is that a working knowledge of the basic executable structure doesn't tell you much about Perl processes and almost nothing about Perl threading.

And, copy on write has almost zero benefit in perl scripts

Well, there's nothing to argue about here. I was not talking about benefits for perl scripts. I've just mentioned existing feature. So, you are right when you say that it does not bring much of benefits for perl because perl scripts are not in code segments but in data segments.

Actually, Perl's threads are very different from your description

It all depends on what is "difference". I only mentioned basic idea of thread vs process. That idea stays the same: thread shares memory of process with other threads. Of course there are different strategies on how that memory is shared and particular sharing may only worsen memory consumption at the end.

The bottom line is that a working knowledge of the basic executable structure doesn't tell you much about Perl processes and almost nothing about Perl threading.

That is true. I just didn't see that the OP wanted to have knowledge about Perl threading. I thought, that the question was more about memory management for Perl. So I pointed out, that perl scripts are loaded into data segment and they don't get shared like segments of perl itself. If I misunderstood the question, then sorry.

Of course there are different strategies on how that memory is shared and particular sharing may only worsen memory consumption at the end.

The main difference between your description and Perl's threading strategy is that in addition to per-thread stack segments, Perl threads have per-thread data segments as well.

You are right that C threads have shared access to all of the process' memory and that the Perl separation is only enforced by Perl. But equally, Perl's lexical variables are "only enforced by perl" and they work quite well.

Also, I know many see those separate data segments as "just chunks of the heap", but the fact is that "the heap" is rarely a single heap in the old sense of the terms; and hasn't been for ... well nearly forever.

Although the "segments" I describe above are actually all just part of a single contiguous virtual address space -- not true segments in the 80286 sense -- if they are each allocated using separate calls to VirtualAlloc() (nmap() I think?), and some (even just a single page of) virtual address space is left unallocated between each of the "segments", then the classical fear of an unbounded loop in one thread succeeding in silently scribbling across all the "segments" cannot happen; as once the loop exceeds the bounds of the segment it started in and hits one of the unallocated (guard) pages, a 'segfault' occurs.

Thus, in most cases, with the language enforcing the allocation of variable addresses and guard pages to detect attempts to cross boundaries, multiple heaps can work very effectively to provide virtual segments that are largely enforced by the hardware without the need for the creation and manipulation of expensive Critical Sections to control access.

Indeed, with Perl thread's explicitly shared data, only the explicitly shared virtual segment needs a CritSec to synchronise access; and because the explicitly sharedness is a language level construct; most of the CritSec manipulations required for the (internal) safety of shared data can be moved internal to the code providing that construct. Some user level locking is required to protect user-level sharing; but internal level sharing is transparent and automatic.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.