> There's a little blurb here about coroutine support as a potential WebAssembly future-feature, but I don't know the state of that.
PS: forgot the link doh: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#coroutines There's also this: https://github.com/WebAssembly/design/issues/1252 On Monday, 8 April 2019 12:19:17 UTC+2, Floh wrote: > > 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]. For more options, visit https://groups.google.com/d/optout.
