Re: THREADS Management XUL/FIREFOX

Takis Psarogiannakopoulos wrote:
> Thats correct still 32, 128 and 4096 as max limit numbers isnt that too
> high? I would say 16 max ...

I'm not sure why those numbers are even being talked about in this 
context....

> Anyways where I am most interested (thats why I posted) is the dns
> resolver. 8 threads with considerably descnt stacks to handle dns
> requests? Why not 4? In fact I have build a FI2 binary on my SVR4 with 4
> such threads and I can tell is much better. So wanted to know how the
> number 8 was choosen.

Looking at the CVS blame for that file (which you could have done 
yourself, of course), points to that number being picked in 
<https://bugzilla.mozilla.org/show_bug.cgi?id=205726>, or rather being 
added there.  There's no justification given for the number.  You'd have 
to ask Darin for his reasons, assuming he remembers 5+ years thence, but 
I suspect it was just a "not too big, not too small" number.

As far as "much better", what exactly was much better?  Would limiting 
the stack size of the threads this code creates actually help your 
situation?  That could certainly be done (and has been considered; see 
https://bugzilla.mozilla.org/show_bug.cgi?id=453403 where Patrick 
proposed dropping the max stack size to 256KB; the only reasons that 
didn't happen are that there was no obvious reason to do it and that 
that sort of change should be done independently).

> I have also reduced the other number from 4 to 3.

That's up to you.  We could even make it a preference, I suppose, if 
there is really a need for it to be tunable....

> Wouldnt should be some kind of managenment control on how many lwps the
> firefox should claim? Instead leaving its modules to go on controlled
> really only by their own local limits?

Extensions can spawn threads as needed.  The JS engine can spawn 
threads.  Web workers can spawn threads.

If a global limit is implemented, what should happen when someone needs 
a thread and the global limit has been hit?

It's really not clear to me what problem needs solving here.  Is the 
worry the kernel overhead of multiple threads?  Is the worry lock 
contention between the multiple threads?  Is the worry something else?

-Boris