I've opened https://github.com/kripken/emscripten/issues/3360


regards,
- Lu

On Wed, Apr 15, 2015 at 4:32 AM, Alon Zakai <[email protected]> wrote:

> 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 a topic in the
> Google Groups "emscripten-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/emscripten-discuss/z2_ScsGrfrA/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.

Reply via email to