Re: Blocking message passing for Workers

On 12/08/14 15:25, Brendan Eich wrote:
> David Bruant wrote:
>> I proposed exposing both here 
>> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
>> Jonas Sicking wasn't sold 
>> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html
>
> You didn't reply, but we now have a good argument thanks to your point 
> here, about reusing async-only JS libraries.
>
>> And I haven't found later replies on this topic.
>
> Alon replied to Jonas, saying somewhat more gently what I said about 
> generators/async-functions/whole-program-CPS-conversion being 
> infeasible for Emscripten:
>
> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html
>
> Jonas's desire for parsimony is a good design bias, but we now have a 
> reason to consider async as well as sync APIs for workers.
>
> However, I'd still want some case analysis. Do we see Emscripten using 
> IndexedDB to emulate a synchronous filesystem? If we have a sync f/s 
> API that's closer to Unix/C, perhaps there's no Emscripten-based need. 
> Cc'ing Alon, assuming Jonas will catch up on the list.
>
> /be
>
Sync IndexedDB API has been experimentally implemented as a diploma 
thesis project, bug 798875.
The patch is quite old, besides a rebase, we would need to update it to 
use PBackground.
Anyway, almost all the mochitests we have for async IDB testing have 
been copied and rewritten to test the experimental sync IDB implementation.

If we need something fast, reviving sync IDB implementation would be 
probably more efficient than designing a sync file system API, 
implementing it and writing tests.
There's also no async file system implementation yet.

Jan

Received on Tuesday, 12 August 2014 19:42:59 UTC