Dan Melomedman writes:
> Sam Varshavchik writes:
>
>> Dan Melomedman writes:
>>> I could be wrong here, but running a process per connection is wasteful
>>> on very busy servers in any case. In other words, correctly designed
>>> multi-threaded (not necessarily on Linux, and not necessarily with
>>> pthreads) servers conserve memory and require less kernel scheduling
>>> overhead if any.
>
>> Only on platforms where processes are expensive. I really don't see much
>> of a difference between a process and a thread.
>
> Expensive in comparison to what?
A thread. There are some platforms <cough>Solaris</cough> <cough>NT</cough>
where for some weird reasons process creation takes a much greater time than
creating a thread, even though there isn't much of a technical difference
between the two.
> There's a difference between a thread that kernel doesn't even see
> (user-space threading library), and a thread that a kernel has to actually
> schedule. In the process case you have the kernel bookkepping structure
> per process.
>
> If you are talking about Linux, and it's default native threading library,
> creating a thread, means creating a process, so there's no difference.
> This does NOT scale well.
Actually it should scale better than trying to do everything yourself. When
you let the OS handle threading, the OS can schedule one thread for
execution when another thread is waiting for I/O. You do not have this
flexibility if you run the threading code yourself.
A lot of thought goes into a typical OS schedule. If you decide to throw
all this away and do the job yourself, it's not going to be easy to do
better than a bunch of code that was already written, optimized, and
debugged for this particular task.
--
Sam
