If the answer is "threads", you asked the wrong question. Threads suck. Event-driven programs and processes are a much cleaner model, with a far better defect ratio.

And a forked program cluster will use your two, four, and 20-way core boxes just fine. No need to introduce the bizarre complexity of threads.

Using threads are like using globals... sure you can do it, but it requires a lot more care. Using fork is like having everything be local to its code and data, which is what you want in a large system anyway.

Son? Hmm, well. I just happen to be some silly 11 days older and sillier than you {g}.

You may have been a bit longer in this business than I (who came to computers off studying architecture around 1989) but I haven't been asleep in the meantime. I also remember the times when a good word processor on the Atari ST (RIP) was worth ~250kBytes on disk; I had my first perl experience with v4.36, and was glad and proud with my simple coding and delighted with Gurusamy's port to the Atari.

That's for that, Father ;-)

But as for threads - set apart the usefulnes of threads, your statement "threads in unix are spelled fork" is blatantly wrong. Threads were invented for a reason which shurely didn't escape you. Which reason? There.

Do threads solve the issues they address, and at which price? Here we might start a discussion, not just saying "threads suck" ("No, they don't suck." - "Yes, they do!" -"NO!") and throwing in false statements in an inflamatory way.

While I also never had the need to use threads, did all I had to do with fork or an event driven model (Event back then, then POE) - so I'm included in that "we were accomplishing" -, I also have to say that "Using threads are like using globals" is misleading, that would be more appropriate "using threads is like using our()".

I agree with you saying "Using fork is like having everything be local to its code and data", which is fine as long as you just want it that way and never ever are in need of shared variables. If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

If you need shared data, you have the option of delegating the data to an external instance or to share it somehow via classical IPC mechanisms, shared memory segments, message queues, pipes and such - but you basically need the same synchronisation mechanisms as with threads (in come semaphores), and sharing complex data structures is IMHO some hells more difficult using IPC.

But that's actually a good thing. The fact that it's a pain to share complex structures will make you rethink your application. If it's easy to share complex data, you'll end up taking a performance hit, because more and more of the data has to be locked because you're doing it blindly.

And the default should be not shared, rather than shared. fork() ensures this. Threads is biased towards shared.

Multiple threads of execution is hard. It should stay hard. There's really no way to make it easy. "threads" pretends to make it easy, and what you end up with are fragile programs because average dudes get in over their head. At least with fork, it's a pain to share things, so average dudes delegate the tricky parts to libraries that do the sharing written by smart dudes, or figure out other ways, like sharing through databases.

Maybe that's why I object to threads: it makes it too easy to get in over your head. It takes far more expertise to use threads than most people have, which is less than they think they have. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.