Re: THREADS Management XUL/FIREFOX

Takis Psarogiannakopoulos wrote:
>> 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.
>>
> I already answered asking this without having seen this message

You said:

   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?

They don't usually lay around.  If they're idle, we shut them down.  If 
they're around that means they're actually busy servicing DNS requests.

> Not clogging the process with unessecary lwps.

Please define "unnecessary"?  And "clogging"?  What's actually better 
from a user-observable point of view?

> You only need to to create those if you really need them.
 > If you dont they why you created them in
> the first place.? Is there is a preformance adavantage?

I'm not sure what you're asking here.  There's absolutely a performance 
advantage to parallelizing DNS requests if those requests are network-bound.

> On DNS resolver there is considerable stack cause you have to carry
> buffers around.

When you say "considerable" what sort of numbers are we talking about?

>> If a global limit is implemented, what should happen when someone needs
>> a thread and the global limit has been hit?
> 
> If what you say its true and we allow to spawn threads arbitrarily then
> most possibly we have an issue really on the *real time* perfromance of
> the evolving firefox process!

Firefox isn't a realtime system.  If you mean user responsiveness, then 
extra threads are (so far) a win in terms of taking work that can happen 
in the background and doing it there without tying up the event loop. 
As long as synchronization between the threads is kept to a minimum, 
there is no problem as far as I can see.  What am I missing?

I agree that "too many" threads could cause contention for hardware 
resources (the processor in particular), which could adversely affect 
user responsiveness.  We're not hitting this, from what I can see, and 
numbers of cores are growing faster than our thread usage at the moment.

Oh, and no one is allowed to spawn threads "arbitrarily".  If a module 
needs to do work in the background it will typically create a single 
thread for this work; there are a very few exceptions (like DNS and 
networking) that use small threadpools because they often have very 
parallel workloads.

> primarily kernel overhead of multiple threads.

Are we talking about very limited hardware with a really crappy kernel? 
  Because I don't seem to recall LWP overhead on Linux, say, being 
particularly noticeable (and the thread overhead is even less on other 
OSes, last I checked).

-Boris