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 11:31:49AM +0200, Wolfram Gloger wrote: > > IMHO it is just wasting time on your part, your patches to > > linuxthreads are so trivial that glibc should do the thing you need by > > default. > > This has come up before, there is no general agreement on this; I > strongly disagree. > > I much prefer to have reasonably large thread stack sizes by default, > rather than being able to create ridicoulous amounts (>1000) of > threads (which, if _required_ by the application, I count as a severe > application bug). 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. It's only a severe bug if the application requires more threads than PTHREAD_THREADS_MAX. And I don't see any reason to define that to a small value. And which applications need a 2 MB stack? Any program requiring it is buggy, because PTHREAD_STACK_SIZE can be very small. If you need a big stack, you must always use pthread_attr_setstacksize(). But if you only need a small stack, you don't need to call pthread_attr_setstacksize(). 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. Jeroen Dekkers -- Jabber ID: jdekkers@jabber.org IRC ID: jeroen@openprojects GNU supporter - http://www.gnu.org
Attachment:
msg00102/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] |