Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simulate delivery of signals to node #10

Open
paddybyers opened this issue Oct 19, 2011 · 1 comment
Open

Simulate delivery of signals to node #10

paddybyers opened this issue Oct 19, 2011 · 1 comment

Comments

@paddybyers
Copy link
Owner

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

@paddybyers
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant