paddybyers/node — Issue #9: Wrapping node as a library
Author: paddybyers
Created: 2011-10-19 15:00:13+00:00
State: open

There are several reasons why on Android it is important to be able to encapsulate node as a library. The key issue is that useful custom modules will be required to call into the Java platform, and will need to have an instance of android.content.Context from a bonafide application (or service) in order to be able to do that. This means that it must be possible to load node.js in-process.

Wrapping node as a library has a few issues:

1) building as a library - not really a big issue, just addressed with an appropriate makefile target.

2) return instead of exit(): however the runtime exits (as a result of an error, signal, or a normal exit) the control flow needs to return to the caller, and it is not acceptable just to call exit().

3) Release of resources. I expect - not confirmed - that in various cases (esp error cases), node is relying on exit() to release native resources, but explicit release of resources is needed when operating as a library.

There are essentially two possible approaches to get the library to return instead of exit():

a) remove all calls to exit() and replace with a return with an error code, extending all APIs where necessary to return error codes. This then has to be able to return normally all the way back to node::Start().

b) longjmp() whereever exit() is called to a context that was created before entering the library, with code at that point to release (previously tracked) resources. Equivalently this could be done with an exception, but I think it is reasonable to put minimal reliance on specific C++ language features.

In the current port we do (2). It requires inclusion of a wrapper.h which redefines exit(x), to avoid having conditions everywhere exit() is called. It also requires node to expose an API that can perform the tidyup that would normally be performed at exit.

The relevant commits are:

https://github.com/paddybyers/node/commit/e35e1dde0b44a8efbc0bf9448c3b7d119ff6b9d1
https://github.com/paddybyers/node/commit/0855f52d69936869308813a1bb6817c5f82743b6

The issue is whether or not this general approach is workable, or if there is support for a better way.