Re: THREADS Management XUL/FIREFOX

On Tue, 17 Feb 2009, Boris Zbarsky wrote:

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

I dont know about those. I just observed too much stck on dnsresolver and
noticed that locally on places mozilla sets limits for threads sometimes
really  a bit silly?

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

> As far as "much better", what exactly was much better?

Not clogging the process with unessecary lwps. 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?

mobile OS's would care for those extra threads.

> 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.
>
On DNS resolver there is considerable stack cause you have to carry
buffers around.

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

>
> 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?
>
primarily kernel overhead of multiple threads.


Sorry didnt see your previous email before

Regards,