- From: Brendan Eich <brendan@secure.meer.net>
- Date: Mon, 11 Aug 2014 17:11:14 -0700
- To: David Bruant <bruant.d@gmail.com>
- CC: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, adelespinasse@gmail.com, public-webapps WG <public-webapps@w3.org>
David Bruant wrote: > Le 09/08/2014 16:22, Brian Kardell a écrit : >> >> On Aug 9, 2014 10:16 AM, "David Bruant" <bruant.d@gmail.com >> <mailto:bruant.d@gmail.com>> wrote: >> > There is still a case for blocking primitives for projects that >> compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3]. >> > >> >> I'm glad to be switching last night's twitter discussion to a bigger >> medium. My question here is: what is the proposal (if there is any) >> to balance these and simultaneously ensure that we don't wind up >> limiting ourselves or providing really bad foot guns or two APIs >> depending on whether you're in the main thread or a worker? >> > There isn't such proposal and I don't think that can exist which is > one reason I'm opposed to the introduction of blocking primitives in > workers. > > I really hope the compile-to-JS use cases will find another way to be > solved. There is no other way. Why are you arguing from dogma instead of reason? There's no *reason* to say worker overhead is so expensive we should not allow authors to create more workers as needed when some block (temporarily, let's hope on non-main-thread sync input operations? /be
Received on Tuesday, 12 August 2014 00:11:47 UTC