This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DLOPEN and Statically linked executable


> More than 1000 threads isn't ridiculous much. Mysql has that many
> threads, some Hurd servers have that many threads, the jabber server
> has that many threads and there are probably more examples.

We'll have to agree to disagree.  IMHO it is never a sound design to
require more than one order of magnitude more threads than you have
CPUs.  Jakub has already stated the problematic waste of resources.

> It's only a severe bug if the application requires more threads than
> PTHREAD_THREADS_MAX.

But so it always does if you have any simplistic "thread per
connection" model, unless you limit yourself to PTHREAD_THREADS_MAX
connections.

> And I don't see any reason to define that to a
> small value.

Neither do I, but I count 1024 as large.

> And which applications need a 2 MB stack?

Many need large stacks.  Numerical simulation code, especially with
Fortran components, comes to mind.

> Any program requiring it is
> buggy, because PTHREAD_STACK_SIZE can be very small.

Yep, so we agree it's a tradeoff.

> There is a difference between what you like and what is a bug: You
> want to use a small number of threads, that's fine. Other people want
> to use large number, that's also fine. Using a large number of threads
> isn't a bug, it's just another way of using threads.

Sorry, IMHO it's usually just an excuse for "I can't deal with a
request queue and a thread pool".

Regards,
Wolfram.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]