Re^6: Utter FUD!

[BrowserUk]

The third and fourth & fifth sentences: a) are hardly tacit agreement; b) show a profound misunderstanding about the way threads works.

There are no "copies" of shared variables, only aliases to them.

Threads do not emulate fork (*). There is no attempt to have the spawned thread continue from the fork point of the parent.

(*)Though they can be used to do so.

[ysth]

Err, you are using alias there in a completely different sense than it is usually used in perl, and I think most people who know the details of how perl magic works would call it a copy, not an alias.

In the sense tye was talking about, which has nothing to do with where a thread starts running, threads emulate fork (and not vfork, either).

[BrowserUk]

Err, you are using alias there in a completely different sense than it is usually used in perl

From shared.xs:

 * Shared scalar (my $s : shared):
 *
 *  SV = PVMG(0x7ba238) at 0x7387a8
 *   FLAGS = (PADMY,GMG,SMG)
 *   MAGIC = 0x824d88
 *     MG_TYPE = PERL_MAGIC_shared_scalar(n)
 *     MG_PTR = 0x810358                <<<< pointer to the shared SV

No data is stored in the alias, it is just a pointer (with some attached magic), to the actual SV containing the data. That's a little fatter than a RV used for aliasing, but not much.

In the sense tye was talking about, which has nothing to do with where a thread starts running, threads emulate fork

A few extracts from the wikipedia page:

• when a process forks, it creates a copy of itself.

  No new process is involved.

• return value in the parent process is the PID of the newly-created child process.

  $$ returns the same value in all threads.

• The fork operation creates a separate address space for the child.

  No separate address space is involved.

• The child process has an exact copy of all the memory segments of the parent process,

  Not everything is copied. For example, lexicals are not cloned unless they are closed over by the thread sub.

  Data in shared scalars are not copied, another alias to it is created.

You might just as well say that forking emulates spawning a thread. After all, fork does spawn a thread. They obviously have similarities, but that's the nature of the beast. But they also have differences.

So no. Spawning an iThread is not exactly the same as spawning a thread in C or assembler. But then spawning a thread in Java, (or Python or Ruby, or LUA or Clean or Pure or O'Caml or OZ or ... ) is not the same as in C either.

Likewise, Perl's arrays are slower and heavier than C's. In the same way as you don't have direct access to shared memory; you don't have direct access to integers floats or strings in Perl. You go through a layer of Perl internals code to get to both. And you reap the benefits from doing so, from both.

Perl's built-in fork emulates *nix fork on Win32 (and OS/2,); threads->new() does not emulate fork. It just does some things that are similar.

Tye's statement has little technical merit, but a lot of political intent.

[ysth]

Maybe this has changed since 5.10.1, but somehow I doubt it.

You don't appear to fall into the category I mentioned who would not call it an alias. Perl magic uses the magic SV as a buffer between whatever accesses the SV and the magic underneath; the SV will have as many usual fields as necessary for this. As an example, here a shared string has two completely separate string buffers:

perl -wle'use B; use threads; use threads::shared; my $s:shared; $s = 
+"123456"; my$t=threads->new(sub{$s}); use Devel::Peek; Dump $s; Dump 
+${ bless(\(my$x=is_shared($s)), "B::SV")->object_2svref }; $t->join()
+'

Re: fork, I think you are willfully misunderstanding what Tye meant by mentioning fork, so I don't care to argue.