Re: Status and usefulness of ithreads in 5.8.0

[Abigail-II]

• "Thread" is a buzzword, fork isn't. Of course, fork has clocked over 30 years of mileage, while threads are the new kid on the block.
• Threads have been invented and reinvented. So we have kernel threads, green threads, posix threads, interpreter threads, etc. It's just like Java, it never works the same twice. fork is just fork, you just pull out your Stevens or other book from your bookshelf, and it just works reliably, with a clear and simple interface.
• Inferior OSses don't have fork.
• Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening. (Note that just *looking* at a variable can mean Perl changes the variable under the hood - it's not a safe operation.) fork is safe for your data, you need to explicitely share data (using shared memory for instance).
• Compared to a select() loop (as provided by for instance POE), threads give you underterministic behaviour, while a select loop gives you deterministic behaviour.
• Do you know which thread is going to handle a send signal? On any signal capable OS? I know when I fork().

[djantzen]

What exactly are you criticizing? Windows? (What makes an "inferior OS"?) Java? No, threading is not just a buzzword, and it frankly doesn't matter that threads have gone through many changes through the years. The history of threads demonstrates that they are not the "new kid on the block". So they've evolved over the years; this is not a useful critique. Threads, at least in their contemporary manifestations as in Win32, Java, and ithreads as of Perl 5.6, allow lightweight and highly manageable distibution of resources -- especially when it comes to interpreted languages due to the overhead of the interpreter or virtual machine -- whereas forked processes are more memory intensive and more difficult to work with. The difference between interprocess and intraprocess communication is a big one.

It's just like Java, it never works the same twice

Really? Core Java has been stable since at least 1997. If you want to criticize Java's stability, please look first at Java extensions like Swing, J2EE, or the implementation of (the recently added) anonymous inner classes. And by the way, threads were built into the language from its very inception, in fact one of the revolutionary aspects of Java was the fact that Gosling/Sun realized the usefulness of threads early on and built that capacity into the language for the 1.0 release. Abigail-II, if you're going to slander another programming language, at least make it believable.

Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening.

The benefit of threading as opposed to forking processes is shared memory space, and that's why Java and threading packages in C++ and Win32 support code that is thread safe. The bottom line is that it's a trade for efficiency in memory usage in exchange for the extra effort it takes to type "sychronized" in your method declarations.

I for one am glad that thread support in Perl is progressing, and that it will be fully realized in Perl 6.

[BazB]

Threads mangle each others variables by default

Not according to perldoc threads:

It is very important to note that variables are not shared between threads, all variables are per default thread local. To use shared variables one must use threads::shared.

[BrowserUk]

I wrote my first multi-threaded app under OS/2 v1.0 in early 1987 whilst working at IBM. The os (at that time called CP/DOS) was still so early in it development the only IO possible was Beep(frequency,duration). Proving that multiple threads were running meant having each thread beep at a different pitch and/or tempo. WinNT is a successor to/deriviative of the same core mechanisms as were developed for OS/2.

They have come a long way in the last 14 years. The 'problems' of synchronisation and re-entrancy are well understood and easily handled.

There are many good reasons to knock Win32. Braindead CLP, bloat, undue care and attention to security issues and fixes. All that source under the lock & key of one of the most predatory companies around.

There seems little benefit in constructing specious arguments against the threading, critical sections and semaphore mechanisms. Some of the bits they actually got right.

[BrentDax]

Threads mangle each others variables by default, and you need to explicitely guard yourself against that from happening. (Note that just *looking* at a variable can mean Perl changes the variable under the hood - it's not a safe operation.) fork is safe for your data, you need to explicitely share data (using shared memory for instance).

Not true. Variables under ithreads (what threads.pm implements) need explicit sharing. (You do this by saying my $variable : shared.) The difference is that Perl still manages your variables, so you don't have the problems inherent in using normal Unix IPC (such as it not meshing well with Perl).

Do you know which thread is going to handle a send signal? On any signal capable OS? I know when I fork().

I'm not sure about this, but I think Perl 5.8's new safe signals have a way to deal with this.

=cut
--Brent Dax
There is no sig.