Although it looks like your advice, when it comes to perl and not general computing, is right:

Without wishing to offend you, this is a Perl forum, and the subject is Perl threads. Ithreads are not forked processes; not pthreads; nor greeen threads; nor any other flavour. COW is not available everywhere, and Ithreads do not (yet) make use of COW anywhere that I am aware of. As such, your prior experience is of little value in a thread relating to them.

I'm still avoiding threads with perl, there's no good reason for lib authors to make their libs thread-safe, thus your perl apps will never be thread-safe, and, there is basically nothing that threading has to offer (well, headaches and longer development times, but if we wanted that, we would be programming java) (But we do get a lot of people who read a book about GUIs, and they can't seem to live without threads these days)

I rarely bother to read threads about web/cgi and related technologies because they don't interest me.

Again, without wishing to offend you, you must have seen the word "threads" in the title of post. You obviously have no interest in threads, so why bother to expend effort to respond? Especially in such a negative vein. Isn't easier to simply note the subject and move on?

FYI. Threads have many, many uses beyond "GUIs", though they are one good use. And despite your undisguised attempts to imply that GUI applications are somehow inferior, for the vast majority of computer users, as opposed to computer technologists and geeks, gui applications are easier to use and allow them to use their computer systems as tools to perform their primary job rolls without having to become computer specialists.

I started to try and explain the way iThreads work, and how they removed the need for the vast majority of modules to have to be coded to be thread safe. At a conservative guess, 90% of the modules on cpan work perfectly well in conjunction with threads, without any special care needing to be taken by their users, beyond not attempting to share objects across threads.

Then I realised that, going by the tone of your post, you simply wouldn't care. You have no interest in threads and your mind is closed to their possibilities. So, I won't bother.

A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

I've no idea who Alan Cox is, but it is apparent that he is just as ill informed on the subject.

I see just the opposite. When you have a situation where you need to share data between separate processes, it is easier for me to use threads and threads::shared. I suppose if you are used to setting up safe shared memory segments for IPC, then it may be easier for you. But I still see in that situation, threads and shared data is easier to setup, and safer. I shudder when I see those shared memory segments which are not cleaned up.....I've seen some shared mem segment apps,which are supposed to clean up after themselves, leave shared memory segments intact, after a kill 9 or a control-c. I will take threads anyday. Additionally, shared mem segments work differently on win32 and unix/linux, so you need to code twice. Whereas threads work the same on win32 and unix/linux, as far as perl code is concerned.

And there is the option of dealing with a gazillion pipes....yuck.

But I agree with you that if you don't need to share data, forking is preferred over threads.

First off, as far as forking is concerned, you're right: by doing the set-up work in the parent, it gets copied into the kids in shared copy-on-write memory. Thus, there is a huge runtime boon to doing that - both in memory and CPU.

That said, threads are another beast. As BrowserUk points out, these are perl threads, which make them a slightly different beast than regular win32- or p- threads.

They're different enough that I don't bother using them. However, I look forward to perl 6 partly for the hopes that by putting threading into the base language, we might get some good, lightweight threads where the types of workarounds that BrowserUk mentioned in his OP are no longer necessary. Of course, what fixing threads does to PONIE in threaded situations ... well, I don't know.

I really wish I had a thread-safe perl where I could just do stuff in parallel and not have to worry about inter-thread communication. I have some very parallelisable tasks in my code which could really gain from this, especially when it's running on multi-CPU machines (usually 4-way machines). Unfortunately, I'm using blessed references all over the place, and the overhead probably would kill me.

A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

I'm assuming this is the Alan Cox in question ? I suppose its all well and good for someone who hacks OS kernels for fun and profit to make such statements. However, as someone who has also hacked kernels (including of the realtime, SMP kind) for fun and profit, I'd adjust Mssr. Cox's assertion a bit:

Threads are for people who can't have better things to do than program state machines.

However, if Thread::Apartment is as capable as current testing indicates, then I'll agree with your assertion that "there's no good reason for lib authors to make their libs thread-safe". Because they won't have to, assuming they're reasonably OO Perl. Just pop them into an apartment thread, and call the methods and/or invoke its closures as needed.

Yes I realize there are issues apartment threading can't solve. But I've managed to get some threads-hostile DBI drivers to behave, and hope to have Tk working soon, which indicates many otherwise threads hostile modules should be supportable.