Update: please note I'm talking about threads in the general sense. See my clarification on Perl threads.
I don't see the appeal of threads. Modern kernels on CPUs with modern MMUs can fork processes with very little effort and switch them pretty quickly. I expect the performance will increase further with time.
I don't even care that much about the performance argument - but it used to be a big problem once upon a time long past, so I thought I should get that out of the way first.
And then there's the real argument: safety. Forked processes default to not sharing; threads default to sharing everything. With the former, you have to explicitly share what you desire to be shared while with the latter you have to explicitly make thread local copies of sensitive data.
Every person in their right mind will tell you that the correct approach to security is to disallow by default and exempt desired interactions. Every Perl programmer worth their salt untaints data by denying anything but explicitly permitted input. The list goes on; the correct approach is always to disallow by default and explictly permit where desired.
Threads break this fundamental principle.
This is hard to argue with - by using threads you inevitably expose yourself to potential for all sorts of bugs. Since correctness is the primary concern in software development, and all else is secondary, I don't really see any choice but forking.
The current state of affairs is not perfect of course; shared memory or other forms of IPC are harder to use in practice than they ought to be.
Makeshifts last the longest.
In reply to Re: Why use threads over processes, or why use processes over threads?
by Aristotle
in thread Why use threads over processes, or why use processes over threads?
by pg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |