On Oct 19, 2006, at 1:00 PM, Topher Fischer wrote:
Dr. Mercer's Computer Architecture (CS345) class gave me my only
experience with a practical use of forking. We wrote a small UNIX
shell, and when the user typed in a command, the program would fork.
This creates a new process with its own memory space, file descriptor
table, signal handlers, etc. The child process would then exec (man 3
exec) the user's command, which takes over the process that was
created
by the fork command. If concurrency is the only goal, then threads
will
usually take care of the problem. However, if you need a
completely new
process with its own resources, then fork you. I mean, then you fork.
If concurrency is the only goal, then it would be best to analyze
your needs before choosing threads over processes. In Linux, at
least, both have similar overhead. Processes simply have a flag that
says that the heap should be copy-on-write instead of shared, IIRC.
The big advantage of a process over a thread is that you get to take
advantage of the built-in memory protection that Linux gives you.
By /not/ sharing memory by default, you knock out the
nondeterministic interleaving of execution threads that you get with
shared memory, which makes understanding your program's behavior much
simpler.
If passing messages or setting up explicit shared memory turns out to
be far more awkward, and your problem doesn't involve too many hairy
locks and such, threads might be a good solution. But in Linux, you
shouldn't reach for them unless you've clearly demonstrated to
yourself that the benefits outweigh the costs.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
