- From: Marcus Geelnard <mage@opera.com>
- Date: Mon, 28 Oct 2013 09:12:41 +0100
- To: Joseph Berkovitz <joe@noteflight.com>, robert@ocallahan.org
- CC: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, Audio WG <public-audio@w3.org>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, s p <sebpiq@gmail.com>
2013-10-25 23:11, Joseph Berkovitz skrev: >> Another thing is that it doesn't really make sense to create 1 worker per node. You'd be much better off using a single worker for all nodes on a given page, or at most one worker per CPU core the system has. > I agree, although I also think this remark of ROC's also highlights the fact that "Worker" has slightly different meanings for different people. > > On the one hand, "Worker" represents the abstract idea of "a designated script running in a controlled, isolated runtime environment". I think that is the way many of us are talking about it. On the other hand, it also represents a pre-existing implementation concept that has various known costs and overheads. > > ..Joe Yes. For instance most implementations consider Workers to be independendent threads that can execute concurrently, which I think is of little use for the audio node use case (I think most nodes would be executed in series anyway). On the ohter hand that's not a requirement for Workers AFAICT (in fact, Presto would execute all Workers in a single OS thread). That's not my main concern though. I'm thinking more about each audio node having it's own, isolated scripting context, which I think would be very useful. The problem then becomes the set-up time & memory overhead for each node: how much does a regular Worker cost in terms of set-up & memory? Unless we want to depart from the ECMAScript specification, we'd at least need a full ECMAScript environment (not sure what cost that implies). /Marcus -- Marcus Geelnard Technical Lead, Mobile Infrastructure Opera Software
Received on Monday, 28 October 2013 08:13:15 UTC