As the main usage of this number is to maintain a fixed thread pool, I feel it might be better to have a higher level API, such as worker pool.
I do agree that thread pool is very useful, but exposing the number of cores directly seems not to be the best solution. We could have a better abstraction, and let UAs to dynamically control the pool to have better throughput. On Wed, May 14, 2014 at 8:17 AM, Rik Cabanier <caban...@gmail.com> wrote: > On Tue, May 13, 2014 at 2:59 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > > On 5/13/14, 2:42 PM, Rik Cabanier wrote: > > > >> Why would that be? Are you burning more CPU resources in servo to do the > >> same thing? > >> > > > > In some cases, possibly yes. > > > > > > If so, that sounds like a problem. > >> > > > > It depends on what your goals are. Any sort of speculation, prefetch or > > prerender is burning more CPU resources to in the end do the same thing. > > But it may provide responsiveness benefits that are worth the extra CPU > > cycles. > > > > Current browsers don't do those things very much in the grand schemed of > > things because they're hard to do without janking the UI. Servo should > not > > have that problem, so it may well do things like speculatively starting > > layout in the background when a script changes styles, for example, and > > throwing the speculation away if more style changes happen before the > > layout is done. > > > I agree that this isn't a problem. Sorry if I sounded critical. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
