100% agree with Floh there.
It was difficult for me too to accept that "blocking" the main thread is
not possible. This is particularly true when porting existing C++
programs, most of them being designed around that idea. You have to
learn the "asynchronous" way of doing things, sometime called the
"callback hell" ;)
While I do understand why we can't block the main thread, I still don't
get why it is not technically possible with WebAssembly to give back
control to the browser in the middle of execution, without relying on
things like Emterpreter (which is a nice thing btw!). WebAssembly is a
VM after all, a "Pause/Freeze" mechanism is not something impossible.
Maybe it's because it is too closely tied to the JS VM (stack frames, etc..)
Le 08/04/2019 à 12:19, Floh a écrit :
Welcome to the wonders of the web platform :)
I remember well how confused I was when starting to tinker with
emscripten, being used to platforms where an application is allowed to
"own the game loop", and blocking calls are not really an issue.
Eventually I came around to accept those restrictions instead of
working around them with hacks (mobile platforms like Android and iOS
have similar restrictions, however on Android it's quite typical to
workaround it by running the actual application code in a separate
thread, and not the "UI thread").
I'm now writing all my cross-platform-code in such an
"asyncronous-friendly" way. Instead of an "owned" game loop there's a
frame-callback, and all IO is asynchronous with callbacks instead of
blocking.
It would be nice to have async-await-style blocking, where control is
given back to the browser runtime in the middle of a function, but the
way this is implemented in many native green-threading-libs (by
switching stack frames with a bit of assembly code) isn't possible in
asm.js / wasm (AFAIK it works with the emterpreter approach though).
With shared-memory-threading support it should also be possible to
workaround those limitations, similar to how it's done on Android. But
I think most (all?) calls to Javascript/HTML5 APIs would still need to
go through the main thread.
There's a little blurb here about coroutine support as a potential
WebAssembly future-feature, but I don't know the state of that.
On Monday, 8 April 2019 09:40:46 UTC+2, [email protected] wrote:
Hello,
I have problems with emcc and node.ja when I test
a small interactive program:
---------- begin test program tst261.c ----------
#include <stdio.h>
int main(int argc, char *argv[])
{
char buf[100];
printf("Your input? ");
fflush(stdout);
while (fgets(buf, sizeof(buf), stdin) != NULL &&
buf[0] != '!') {
printf("You typed: %s", buf);
printf("Your input (Use ! to terminate)? ");
fflush(stdout);
}
return 0;
}
---------- end test program tst261.c ----------
When I use gcc and run the program afterwards it looks like follows:
myPrompt> gcc tst261.c -o tst261
myPrompt> ./tst261
Your input? test
You typed: test
Your input (Use ! to terminate)? another test
You typed: another test
Your input (Use ! to terminate)? !
myPrompt>
As you can see input and output can alternate.
With emcc and node.js it looks like follows:
myPrompt> emcc tst261.c -o tst261.js
myPrompt> node tst261.js
test
another test
!
<<< Here I typed cntl-d >>>
Your input? You typed: test
Your input (Use ! to terminate)? You typed: another test
stdio streams had content in them that was not flushed. you
should set EXIT_RUNTIME to 1 (see the FAQ), or make sure to emit a
newline when you printf etc.
myPrompt>
As you can see: After the start of the program all the
input must be typed in followed by cntl-d at the beginnig of a line.
Afterwards the program processes all given input in one batch.
Interestingly it is also possible to press cntl-d several times:
myPrompt> node tst261.js
test
<<< Here I typed cntl-d >>>
Your input? You typed: test
another test
<<< Here I typed cntl-d >>>
Your input (Use ! to terminate)? You typed: another test
!
<<< Here I typed cntl-d >>>
stdio streams had content in them that was not flushed. you
should set EXIT_RUNTIME to 1 (see the FAQ), or make sure to emit a
newline when you printf etc.
myPrompt>
I know that Javascript is single threaded, uses an event loop
and works with asynchronous I/O. But I think that it should be
possible to base a synchonous I/O on an asynchronous one.
All JavaScript "solutions" I found in the internet suggest, that
the program must register some callback (or use a Promise) an then
needs to terminate. Afterwards the event loop would call the callback
respecively Promise. In any such case the program is terminated
and executes in a callback function.
In the days when Pascal and other programming languages experimented
with cooperative multitasking it was always possible to write
such a simple interactive program like above. The sychronous
input function entered the event loop (where other events would be
handled just like the Javascript event loop does) and it came back,
when a keyboard input had been typed in.
I really cannot believe that it is not possible to compile such
a simple interactive program with emcc.
I have just started to compile my project (Seed7) with emcc.
Several things already work good, but interactive things do not.
I also need a synchronous solution to read single keypresses
without echo and a function to detect if a key has been pressed.
First I target node.js, but later the browsers are also a target.
Many thanks in advance for your help.
Regards,
Thomas Mertes
--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
--
You received this message because you are subscribed to the Google
Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.