Re: help with huge memory consumption??

"David Schwartz" <davids@xxxxxxxxxxxxx> writes:
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.

Trivial counterexample:

int main(void)
{
if (fork()) wait(NULL);
else sleep(3);

return 0;
}

and

void *sleeper(void *unused)
{
sleep(3);
return NULL;
}

int main(void)
{
pthread_t tid;

pthread_create(&tid, NULL, sleeper, NULL);
pthread_join(tid);
return 0;
}
[not compiled and not tested -- fix bugs if you would like to try]


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.

It is not possible to compare 'n * X' with the result of 'Y * <infinity>'
because the latter cannot be calculated (X, Y being integral numbers
0). But that doesn't mean that 'n * X' cannot be compared to 'm *
Y', as you claim.

An I can, of course, implement a 'process pool' server, for instance,
by passing descriptors refering to new connections to waiting
processes over an AF_UNIX socket (or, even simpler, have all processes
call accept on a socket created by their common parent, do connection
related processing until shutdown and then call accept again).
.

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??
    ... would be a strong hint at a deficiency in the kernel. ... 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 ...
    (comp.os.linux.development.system)
  • Re: Is this a reason?
    ... If I configure the same cost, our emails are automatically routed to the XYZ ... For example, unless the RG1RG2 connection is down, mail from RG2 to ... Routing group1: member-one ABC's FE server ... Routing group 2: member-ABC's two backend servers and one XYZ's backend ...
    (microsoft.public.exchange.admin)
  • Re: How to connect an off-site server to SBS 2003 network.
    ... server of there to make a connection to our ERP system. ... Cost is definatley a factor, so the cheapest way to get ... VPN is one option; a leased line is another. ...
    (microsoft.public.windows.server.sbs)
  • Re: SQLConnect Question
    ... of maintainability, good performance for the user, stress on the server, ... cost of licenses, total cost of ownership. ... >> turn on the connection only when needed and turn it off when it is idle. ... > Persistent connection usually means more licenses to connect to the SQL ...
    (microsoft.public.fox.programmer.exchange)