V8 script contexts created through the vm module
Tomasz Janczuk
contexts created through the vm module:
1. What is the lifetime of these script context? When is the script
context along with the global object subject to garbage collection?
2. If code that runs in a script context initiates an asynchronous
operation (e.g. setTimout or http.request), does it prevent the script
context from being disposed?
3. Is there a way to find out whether completion of any asynchronous
operations is pending for a given script context? For example, once
the vm.runInScriptContext returns, is there a way to determine if the
code that run in it is "done" or whether it is waiting for any events
to arrive in the future?
4. Exceptions thrown from async callbacks running in a script context
can be caught using the uncaughtException handler in the "parent"
script context. However, that exception seems to lack any detail
related to which code/script context it originates from. Is there a
way to get more information about the source of the exception?
5. What happens with the script context that generated the exception
that had only been caught with the uncaughtException handler in the
"parent" script context?
Thanks,
Tomek
Ben Noordhuis
> I have a few questions regarding the rules governing V8 script
> contexts created through the vm module:
>
> 1. What is the lifetime of these script context? When is the script
> context along with the global object subject to garbage collection?
Once there are no more live references to them, same as any other JS object.
> 2. If code that runs in a script context initiates an asynchronous
> operation (e.g. setTimout or http.request), does it prevent the script
> context from being disposed?
If by 'disposed' you mean 'kill the context and everything in it',
that won't (shouldn't) happen.
> 3. Is there a way to find out whether completion of any asynchronous
> operations is pending for a given script context? For example, once
> the vm.runInScriptContext returns, is there a way to determine if the
> code that run in it is "done" or whether it is waiting for any events
> to arrive in the future?
No. You have to keep track of that yourself. The domains feature that
is scheduled for v0.8 may change that.
> 4. Exceptions thrown from async callbacks running in a script context
> can be caught using the uncaughtException handler in the "parent"
> script context. However, that exception seems to lack any detail
> related to which code/script context it originates from. Is there a
> way to get more information about the source of the exception?
You can pass a filename parameter to the vm.* functions but admittedly
it doesn't do much. The answer to this question is mostly 'no'.
> 5. What happens with the script context that generated the exception
> that had only been caught with the uncaughtException handler in the
> "parent" script context?
See #1, it eventually gets reaped by the garbage collector.
uncaughtException is a great way to leak resources by the way, inside
and outside of script contexts.
Tomasz Janczuk
Re: 3. I notice an [undocumented] process.uvCounters() function. It
looks potentially interesting. What exactly does it do?
Ben Noordhuis
It's less interesting than it looks: it's a debugging tool, a counter
of the number of handles (sockets, pipes, etc.) created so far. No
guarantees are made about its accuracy. :-)