W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Sync API for workers

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 04 Sep 2012 22:33:35 +0200
Message-ID: <5046659F.30106@gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, Alon Zakai <azakai@mozilla.com>
[Forwarding a response from Alon Zakai, who is behind Emscripten and
CC'ing him]
>>>  There is also another use-case which has been brought up. As the
>>>  web
>>>  platform is becoming more powerful, people have started converting
>>>  code written for other platforms to javascript+html.
>> By "html", here, do you mean something else than<canvas>?
>> Is there something that compiles any Windows/Mac/Linus UI framework
>> into
>> "HTML5"?
> There is pyjamas that compiles Python into JS and GWT that compiles Java into JS. Both are UI frameworks, and being able to use sync calls in both would be more natural since the original languages have lots of sync stuff I believe. I don't know how important this use case is though. But we would like to compile open source UI frameworks like Qt and GTK into JS using emscripten, and sync would help a lot there.
>>>  For example the
>>>  emscipten[1] and mandreel[2] allow recompiling C++ code to
>>>  javascript
>>>  which is then run in a web browser.
>> I've been following loosely this topic and all examples I've seen
>> were
>> either about pure computation (like turning a C GZIP library in JS)
>> or
>> graphics stuffs (using canvas, hence my above question).
>>>  Many times such code relies on APIs or libraries which contain
>>>  blockingcalls.
>> Do you have an example of that? I haven't seen one so far, but that's
>> an
>> interesting point.
>> Specifically, I can't recall having seen any C/C++->JS example that
>> were
>> doing IO (maybe files, but not network),
>> Last I heard, Emscripten compiles to JS from LLVM bytecode. I'm not
>> sure
>> they rely on any library containing blocking calls.
>> But as I said, I have been following that loosely.
> The normal C/C++ IO calls are all synchronous - fopen, fread, etc.
> As you said above, this is indeed less of a problem for pure computation. But when compiling a complete game engine for example (like in BananaBread), you need to handle everything a complete app needs, including synchronous IO. Both file IO and and network IO (for multiplayer, downloading assets, etc. - we haven't gotten around to that yet though in BananaBread) are relevant, as well as synchronous GL operations using WebGL.
>>>  Technically it might
>>>  be possible to automatically rewrite such code to use asynchronous
>>>  coding patterns, but so far I don't think anyone has managed to do
>>>  that.
>> Naively, I would say, that once we've paid the price to compile code
>> from one language to another, you're not that far off from compiling
>> to
>> a given coding pattern. Especially compiling from LLVM bytecode.
>> Regardless, has anyone tried at all? Has anyone tried to compile to
>> JS+Promises or JS+task.js?
> Consider even the simple and very common case of
> ..
> while (!feof(f)) {
>   fread(buf, 100, 1, f);
>   ..process data in buf..
> }
> ..
> I don't have any good ideas for something asynchronous to compile this into that does not currently substantially harm performance. Compiling synchronous code into continuation passing style, generators, control flow emulation, or some other async style would greatly reduce performance. In theory JS engines could optimize those styles, but it would be hard and I don't think this is at the top of anyone's list of priorities for any JS engine.
> Now, we could say that sync code, mainly IO, will run slowly but that is ok because it's mainly just done during startup. That's true to some extent, but startup is very important too, in BananaBread we already have 5-10 seconds or so to load the entire game engine, a lot of which is file IO and processing, and we have gotten requests to improve that as much as possible because it is very significant for the user's initial impression.
> Best,
>   Alon Zakai
Received on Tuesday, 4 September 2012 20:34:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC