>> Thank you James for that detailed explanation. Since I havent
>> dont production level multithreading yet, Im wondering is seperate
>> process more common in full on production servers or is
I am not James, but I reply anyway.
It probably has a *lot* to do with the application: do the connections
need to share read/write data? and so on. And on whether the
programmer is the kind of Unix programmer who dislikes threads strongly:
Also note that these are not the only two alternatives. One
thread/process per client is not the only alternative, either.
Apache httpd implements several different models; you may want to
google for information and opinions on those.
>> I could go with either as this particular application wont exceed 250
>> threads/processes, but I know that in the past I worked on something that
>> could potentially have 40k+ threads
40000 threads seems like a bad idea, but it might be OK if it's some
special language-specific kind of thread.
See for example this discussion over at comp.protocols.tcp-ip:
<< XXXX@XXXXX.COM >>
>> and Im assuming processes are heavier
>> than threads overall for resource consumption etc.
If you are on Unix (which you appear to be), you shouldn't assume
that. A fork(2) can be surprisingly fast, and after the fork you
don't have to care about synchronization, rare deadlock bugs and
tedious stuff like that.
// Jorgen Grahn<
\X/ snipabacken.s>> O o .