Re: help with huge memory consumption??

On Mar 8, 6:41 am, Rainer Weikusat <rainer.weiku...@xxxxxxxxx> wrote:
"David Schwartz" <dav...@xxxxxxxxxxxxx> writes:

On a system that has only ever supported 1:1 threading as default
model, 'process creation' being much slower than 'thread creation'
would be a strong hint at a deficiency in the kernel. But reportedly, the
difference is negligible on Linux, so your assumption should be
wrong. And it is a strawman, except if you constrict yourself to a set
of real-world cases where the reason you try to shoot down actually
was the reason to use threads.

This is a nonsensical reply.

It should be easy for you, then, to not only label it the way you
would like others to regard it, but to point out in detail which parts
of it are nonsensical for what reasons.

Because thread creation is in no way analogous to process creation.
There is no case where you think, "hmm, I could create a thread or a
process, I wonder which is cheaper". So it's nonsensical to compare
their costs.

Thread creation is in no way analogous to process creation.

On Linux, using the default threading implementation, both are
ultimatively created by using the same system call (clone(2)) and
implemented with the same system mechanism (things the kernel sees as
'tasks' by means of a struct task_struct), so they are not only
analogous but nearly identical.

That they are done the same way does not make them analogous if the
results are incomparable!

Threads are reusable, processes are not.

What is 'threads are reusable' supposed to mean?

It means that you need to create a thread when, and only when, you
need more threads than you have already created. However, you need to
create a process not just when you need more processes but when you
need different processes.

As a trivial example, consider a thread pool versus a 'fork after
accept' server. The thread pool server will create some maximum number
of threads over its life and will reuse them. The cost of a thread
creation per client is effectively nearly zero. A 'fork after accept'
server will create one process for each client it handles. The cost of
a process creation is a per connection cost.

So it makes no sense whatsoever to compare the cost of one to the cost
of the other. There is essentially no actual circumstance where one
has the choice to do one or do the other the same number of times.

DS

.

Relevant Pages

  • Re: help with huge memory consumption??
    ... | Because thread creation is in no way analogous to process creation. ... So it's nonsensical to compare ... Linux clone() call is not too far from this. ... The cost of a thread ...
    (comp.os.linux.development.system)
  • Re: help with huge memory consumption??
    ... Because thread creation is in no way analogous to process creation. ... The thread pool server will create some maximum number ... The cost of a thread ... a process creation is a per connection cost. ...
    (comp.os.linux.development.system)
  • Re: [PATCH 2/2] Add support for in-kernel process creation during restart
    ... process creation more easy. ... This information (and the pids of children) is already available in ... why do you want to start the container in the kernel? ...
    (Linux-Kernel)
  • Re: help with huge memory consumption??
    ... 'process creation' being much slower than 'thread creation' ... would be a strong hint at a deficiency in the kernel. ... was the reason to use threads. ... implemented with the same system mechanism (things the kernel sees as ...
    (comp.os.linux.development.system)
  • Promise or 3Ware?
    ... The server will run debian with kernel 2.6. ... The cost ...
    (Debian-User)