Hi Brion,
I tried to add callback to the App as a member (m_cb) but it doesn't help.
App still alive but callback dies somewhere inside
m_requestManager.call<void>("sendRequest", m_cb).
I suspect that inside call method we have a copy of m_call instead of
reference to m_call and this copy dies when we get out from the JS function
scope (but m_cb still alive as a member of App), but I can be wrong...
I created an issue in Emscripten
repo: https://github.com/kripken/emscripten/issues/4154
On Tuesday, March 8, 2016 at 7:52:02 PM UTC+1, Brion Vibber wrote:
>
> On Mon, Mar 7, 2016 at 9:50 AM, Andrii Heonia <[email protected]
> <javascript:>> wrote:
>
>> This is demo with global callback:
>> https://github.com/AndriiHeonia/async-emcc/tree/7207aebdcc65b5d183f1a26516ccdd77eb06ce8e
>> and
>> it also doesn't work. My callback dies before async call even if it is
>> global (and I don't get how to keep it alive)
>>
>
> Yeah, I'm seeing the same thing with this example, can't quite see what's
> forcing the object to get deleted after the sync call code-path. Seems the
> same if I switch from raw pointers to std::shared_ptr...
>
> Andrii, if you can't get this worked out I would recommend switching from
> storing the Callback in a C++ global to instantiating an App object from
> the JS side and letting the Callback instance live as a member variable in
> the App instance.
>
> This should allow you to control the lifetime of the App instance from the
> JS side more explicitly (eg, it should stay alive until you explicitly
> destroy it from JS).
>
> -- brion
>
--
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.
