Re: THREADS Management XUL/FIREFOX

Takis Psarogiannakopoulos wrote:
> mozilla/netwerk/dns/src/nsHostResolver.cpp:#define MAX_THREADS 8

These are threads that run only one small function; they spend most of 
their time waiting on getaddrinfo() system calls.  They shouldn't have 
much of a stack.  If this is being an issue in practice we can limit the 
max stack of these threads, but is it actually more expensive to allow 
(but not use) a bigger stack?

> mozilla/netwerk/base/src/nsIOThreadPool.cpp:#define MAX_THREADS 4

These are threads that handle network I/O.  They don't ever have much 
code running on them, and again then spend most of their time waiting on 
the network.

> mozilla/security/nss/cmd/vfyserv/vfyserv.h:#define MAX_THREADS 32

This is a sample SSL server.  It's not used in Firefox code.

> mozilla/security/nss/cmd/strsclnt/strsclnt.c:#define MAX_THREADS 128

This is a test SSL client used to stress-test the SSL implentation. 
It's not used in Firefox code.

> mozilla/security/nss/cmd/selfserv/selfserv.c:#define MAX_THREADS 4096

This is an SSL server.  It's not used in Firefox code.

Do keep in mind that NSS is used in server-side SSL products, not just 
in Firefox, right?

> Now 8 threads in a process is already a fair amount of overhead if you
> assume they are allowed to run with a descent stack.

If they're allowed, or if they do?

> I would say optimum 4-6 I  its good for most systems.

Is there data to back this up?

> Eg I know from a fact that
> over 9 threads on a recent Xlib (R70) and you are bound to run on
> syncronization issues one way or another.

Even if all the threads are spending most of their time in i/o wait?

> I was wondering: is there is a max number of threads that, say, the
> firefox process can create?

Not that I know of.

> In other words is there is a global limit for the number of LWP?

Not that I know of.

 > 32 also way too much.

That depends on what they're doing, really.  If most of them spend most 
of their time sleeping, there is no problem other than the kernel 
accounting needed to keep track of them, no?

> Moreover the DNS resolver is allowed just by it self to create 8 different
> threads?

Yes, if someone tries to resolve 8 different addresses at once.  Note 
that the threads are reaped after an idle timeout, by the way.

> Isnt that too much?

Not that we've seen so far.  Do you have data showing that it is?

> (please note the dns resolver threads
> there are lwps that need a a fair amount of stack too for the job are
> intented to do!)

They do?  Why?

-Boris