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


On Fri, Jun 21, 2002 at 01:37:59PM +0200, Wolfram Gloger wrote:
> > 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.

If you have light-weight threads like the L4 kernel (see
http://www.l4ka.org for more information) you don't have to care about
that. The problem is that in Linux threads are implemented as
processes with their memory shared and that's pretty heavy. IMHO Linux
has the broken design here, not the program using a lot of
threads. But when you have a mix of user-level and kernel-level
threads you waste less resources. If you search the libc-hacker
archive you will see some discussion about this.

> > 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.

Pthread_create() will return EAGAIN when the maximum number of threads
and then the program will refuse the connection or try free some
threads or something like that. But I actually don't want this to
happen, we should avoid these kind of limits.
 
> > And I don't see any reason to define that to a
> > small value.
> 
> Neither do I, but I count 1024 as large.

It's large, but I see no reason to forbid more threads.
 
> > And which applications need a 2 MB stack?
> 
> Many need large stacks.  Numerical simulation code, especially with
> Fortran components, comes to mind.

Yes, and those can tell the pthreads library that they want a big 
 
> > Any program requiring it is
> > buggy, because PTHREAD_STACK_SIZE can be very small.
> 
> Yep, so we agree it's a tradeoff.

No. I say that a program should *always* specify the stacksize when it
needs a big stack.
 
> > 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".

No, not really. If you have 1000 simultaneous connection (for example
with the jabber server) then you want 1000 threads, one thread for
each connection. For a very busy server, handling thousands of users,
I think that using 1000 threads isn't really wrong. 

And as glibc is part of the GNU it has to follow the GNU Coding
Standards and it says this about limits: 
"Avoid arbitrary limits on the length or number of _any_ data
structure, including file names, lines, files, and symbols, by
allocating all data structures dynamically.  In most Unix utilities,
"long lines are silently truncated".  This is not acceptable in a GNU
utility."

And I agree with it, you should avoid limits whereever
possible. That's why I want to have the default stack size not that
big so you don't waste too much virtual memory. When you want bigger
stacks, you can specify it. Of course this only matters for 32-bit
architectures, 64-bit architectures have enough virtual memory.

Jeroen Dekkers
-- 
Jabber ID: jdekkers@jabber.org  IRC ID: jeroen@openprojects
GNU supporter - http://www.gnu.org

Attachment: msg00112/pgp00000.pgp
Description: PGP signature


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