- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 12 Aug 2014 16:21:32 +0200
- To: Brendan Eich <brendan@secure.meer.net>
- CC: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, adelespinasse@gmail.com, public-webapps WG <public-webapps@w3.org>
Le 12/08/2014 02:11, Brendan Eich a écrit : > 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? It won't be possible to run the same code (libraries) in workers and main thread. That's a reason, not a dogma. People already don't use workers that much (because of copy cost outweighing computing in most use cases and too many people are still unaware of transferables). > 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 hope? Who was taking about reason? :-p I don't think hoping for reasonable behaviors from authors works at scale, do you? People copy/paste, put copy/pasted code in loop bodies without looking into it too much (it's not even funny how often people ask me for JS perf advice which ends up being some equivalent of "cache this jQuery call in a variable"). With C, Java and all, we already know where adding blocking I/O primitives leads to. Admittedly maybe dogma trying to learn from history. > on non-main-thread sync input operations? Why haven't workers begun with sync primitives? David
Received on Tuesday, 12 August 2014 14:22:06 UTC