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