paddybyers / node

evented I/O for v8 javascript
http://nodejs.org/
Other
91 stars 24 forks source link

Wrapping node as a library #9

Closed paddybyers closed 12 years ago

paddybyers commented 12 years ago

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.

paddybyers commented 12 years ago

The associated change for master is here:

https://github.com/paddybyers/node/commit/7d69fad5c8f32093cf2f5c13cac41a199b013c63

paddybyers commented 12 years ago

This is now part of the more general issue relating to multiple instances:

https://github.com/paddybyers/node/issues/16