You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running as a library inside an Android Java application, it is not possible to send signals to node in the usual way without killing the Java VM.
However, there is a desire to be able to programmatically simulate the delivery of these signals. In particular, there needs to be a way of asynchronously terminating an instance from a separate thread while the main thread is blocked inside libev in the event loop.
The proposal is to expose an API at the top--level that calls the relevant functionality in libev.
It's more difficult than this in general because of the issues of signals and multiple threads. In libev, only one event loop can be associated with any given signal. This means that even with ev_feed_signal you cannot programmatically deliver an simulated signal to an arbitrary loop. It also means that SIGCHILD processing (for child_watcher) is only possible in the default event loop, which isn't good enough for us.
Now asynchronous programmatic termination is being done by a combination of steps.
First, an async watcher is created and initialised when the isolate starts, but the watcher is not started. This means that the existence of the watcher, by itself, does not prevent a normal exit.
Termination performs two distinct operations:
signals the async watcher (which will wake up an idle event loop). In the async callback, an ev_break() is performed, which causes the loop to exit on return from the callback;
forcibly terminates execution of the v8 isolate; so if the event loop was not idle, javascript execution will end via an uncatchable termination exception. Once javascript returns to the event loop, the break event will be processed.
There is possibly an issue here with events that were pending prior to termination of the isolate - I need to check what happens in this case. I think I need a prepare watcher to do the break to guarantee that no max priority pending events can be run.
When running as a library inside an Android Java application, it is not possible to send signals to node in the usual way without killing the Java VM.
However, there is a desire to be able to programmatically simulate the delivery of these signals. In particular, there needs to be a way of asynchronously terminating an instance from a separate thread while the main thread is blocked inside libev in the event loop.
The proposal is to expose an API at the top--level that calls the relevant functionality in libev.
Suggested commit is here:
9f6f9e0
The text was updated successfully, but these errors were encountered: