Re: THREADS Management XUL/FIREFOX

Borris its too late here so I'l address only this:

On Tue, 17 Feb 2009, Boris Zbarsky wrote:

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

Yes but the function will normally will go in a shared library lresolv or
similar to address this. In other words will go through nspr
prnetdb.c For some reason the code there adds a considerable amount of
stack. There is a buffer to consider when you call reentrant gethostbyname
etc. My primary question here is: why the number 8? Why eg 4 or 5 which
seems more reasonable. If the threads are spending so little time active
why having 8 laying around?

Btw if you restrict their stack too much you would have a problem. Eg in
my SVR4 if they go out of stack they signal SIGSEGV to the process. This
is the case for those threads.
I would also say that in the design of an OS realistically there is a
consideration of how many lwps are in a process regarding real time
performance.


Regards,