I suspect postRun is not much tested actually. Perhaps we should deprecate it? Or look at a testcase to fix.
Regarding exit not always exiting the emterpreter, a testcase would be good. - Alon On Tue, Apr 14, 2015 at 12:59 AM, 王璐 <[email protected]> wrote: > I've incorporated the new way into my game. All the > `while(blocking)sleep(); get_result()` patterns have been replace by > `EmterpreterAsync.handle(..)` > I do feel that the program is a bit more responsive. > > More issues I've found: > > postRun no loner works, is there a standard way to inject functions upon > exit? > > Seems that sometimes `exit` termintates emterpreter, but sometimes it does > not. Shall I use emscripten_force_exit? > > > Thanks a lot! > > > regards, > - Lu > > > On Monday, April 13, 2015 at 7:19:14 PM UTC+8, 王璐 wrote: >> >> So now what I understood is, `Emterpreter.handle` should occupy the whole >> function, or other parts might be execute twice? >> For example: >> >> function f() { >> do_something(); >> EmterpreterAsync.handle(..); >> do_something_else(); >> } >> >> Then both do_something/do_something_else might be called twice >> (unexpected). >> >> Further, if C code calls a 'nested' EmterpreterAsync.handle, like this >> >> func_in_C -> func1_in_js -> ... -> funcN_in_js -> EmterpreterAsync.handle, >> >> so everything in the chain will be called twice, as EmterpreterAsync only >> interprets the C code. Am I right? >> >> >> >> On Monday, April 13, 2015 at 7:06:00 AM UTC+8, Alon Zakai wrote: >>> >>> Yes, and resume occurs in fact before you reach the end of that method, >>> on the *second* time it is called, when it is restarted. So if you save the >>> return value somewhere, you can just return it there. But, this is >>> confusing. >>> >>> So we should have a proper API for this. I implemented one in >>> >>> https://github.com/kripken/emscripten/commit/ >>> d80417c665dd45e1893cb85aa8523efe57c7d58c >>> >>> , see the testcase there. The resume() function has a post argument, >>> which runs right after the stack was recreated and we are about to finish >>> the async operation. That means it is right before the async-causing >>> function exits, so it is a proper time to return a value. I made it so >>> return values from that post will be returned. Note that you need to return >>> EmterpreterAsync.handle() for that to work, as in the testcase in that >>> commit. >>> >>> - Alon >>> >>> >>> On Fri, Apr 10, 2015 at 8:37 PM, 王璐 <[email protected]> wrote: >>> >>>> Did you mean something like this? >>>> >>>> EmterpreterAsync.handle(...); >>>> return something; >>>> >>>> >>>> But the return value might not be available until the callback, e.g. to >>>> get a key input, so I need to set the return value in `resume`. >>>> >>>> >>>> >>>> regards, >>>> - Lu >>>> >>>> On Saturday, April 11, 2015 at 5:07:37 AM UTC+8, Alon Zakai wrote: >>>>> >>>>> I think if you add a return in g - outside of the handle() call - it >>>>> will just be returned. It will however be returned both the first time >>>>> when >>>>> called (and starting to unwind the stack) and the second time when >>>>> restarted (after reconstructing the stack). You could tell which of those >>>>> you are in using EmterpreterAsync.state. Might be nicer to add an API for >>>>> that. >>>>> >>>>> - Alon >>>>> >>>>> >>>>> On Fri, Apr 10, 2015 at 3:47 AM, Lu Wang <[email protected]> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Is there a way to return something from an async function with >>>>>> emterpreter? For example: >>>>>> >>>>>> ///main.c >>>>>> void f() { >>>>>> printf("%d\n", g()); >>>>>> } >>>>>> >>>>>> ///main.js >>>>>> function g() { >>>>>> EmterpreterAsync.handle(function(resume) { >>>>>> setTimeout(function() { >>>>>> resume(return_value); // ??? >>>>>> }, 1000); >>>>>> }); >>>>>> } >>>>>> >>>>>> >>>>>> I saw that `resume` already takes a few parameters, so maybe we >>>>>> cannot simply do so. Currently the closet way is to write the return >>>>>> value >>>>>> into some memory address, but it would be better if the return value can >>>>>> be >>>>>> passed directly to the C code. >>>>>> >>>>>> >>>>>> regards, >>>>>> - Lu >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> >>> -- > 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. > -- 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.
