C++ embedder question: Can node::Environment (or NodeJS instances) run more than one script at a time?

[benjamintli]

• Node.js Version: 15.0
• OS: MacOS
• Scope (install, code, runtime, meta, other?): code
• Module (and version) (if relevant):

Hi, Im trying out the C++ embedder API and one thing I'm confused about is multiple runs of a script in the same environment. In the code below (taken from the NodeJS docs) a new environment setup is created per script run, and if I'm understanding it correctly it creates its own event loop, isolate, and context. And then when we load a node environment itll take all those and execute a script within that environment. I want to be able to reduce the amount of overhead in running a script, is it possible to share this CommonEnvironmentSetup object? Can we have say, a class that creates V8, initializes node and an event loop + isolate + anything else we need and then have a method in that class that just injects the script into the environment and runs it?

int RunNodeInstance(MultiIsolatePlatform* platform,
                    const std::vector<std::string>& args,
                    const std::vector<std::string>& exec_args) {
  int exit_code = 0;

  // Setup up a libuv event loop, v8::Isolate, and Node.js Environment.
  std::vector<std::string> errors;
  std::unique_ptr<CommonEnvironmentSetup> setup =
      CommonEnvironmentSetup::Create(platform, &errors, args, exec_args);
  if (!setup) {
    for (const std::string& err : errors)
      fprintf(stderr, "%s: %s\n", args[0].c_str(), err.c_str());
    return 1;
  }

  Isolate* isolate = setup->isolate();
  Environment* env = setup->env();

  {
    Locker locker(isolate);
    Isolate::Scope isolate_scope(isolate);
    // The v8::Context needs to be entered when node::CreateEnvironment() and
    // node::LoadEnvironment() are being called.
    Context::Scope context_scope(setup->context());

    // Set up the Node.js instance for execution, and run code inside of it.
    // There is also a variant that takes a callback and provides it with
    // the `require` and `process` objects, so that it can manually compile
    // and run scripts as needed.
    // The `require` function inside this script does *not* access the file
    // system, and can only load built-in Node.js modules.
    // `module.createRequire()` is being used to create one that is able to
    // load files from the disk, and uses the standard CommonJS file loader
    // instead of the internal-only `require` function.
    MaybeLocal<Value> loadenv_ret = node::LoadEnvironment(
        env,
        "const publicRequire ="
        "  require('module').createRequire(process.cwd() + '/');"
        "globalThis.require = publicRequire;"
        "require('vm').runInThisContext(process.argv[1]);");

    if (loadenv_ret.IsEmpty())  // There has been a JS exception.
      return 1;

    exit_code = node::SpinEventLoop(env).FromMaybe(1);

    // node::Stop() can be used to explicitly stop the event loop and keep
    // further JavaScript from running. It can be called from any thread,
    // and will act like worker.terminate() if called from another thread.
    node::Stop(env);
  }

  return exit_code;
}

-->

[addaleax]

So … there’s a few possible things you might be talking about, and it’s not super clear to me which one it is:

• Multiple Environment instances can share the same Isolate and event loop, that’s okay. You can create a new Context and Environment for each script you want to run, which would make them mostly independent from Node.js’s point of view. This requires setting up these objects manually, e.g. the way it was done before CommonEnvironmentSetup: https://nodejs.org/docs/v14.15.0/api/embedding.html
• You can also run multiple scripts per Environment, that’s no problem at all. In that case, you can use the V8 Script class to compile and run individual scripts. In that case, you may want to use the overload of LoadEnvironment that takes a StartExecutionCallback callback instead, so that you have raw access to the objects that Node.js provides to you.

Is that helpful? If not, can you clarify a bit more which things you want shared between the different scripts or not?

The title of this issue might also hint at running multiple scripts in parallel – you can’t share an event loop or Isolate instance between threads, if that’s what you’re referring to. If this is your goal, you can use worker threads or emulate them manually.

[benjamintli]

Hi, thanks for the reply! Super super helpful, that's exactly what I was looking for. The V8 docs mention that creating a new context is not that expensive (after the first one) due to caching, is that a correct thing to assume? What's the situation where having a new context is desirable over reusing an existing one? In my case each script I run could have some arbitrary npm dependencies (the script will come from a path that's pulled before the embedder runs). Is it better in my case to start with a new context per run? Thanks again, very helpful!

[addaleax]

@benjamintli It’s probably still relatively expensive to spin up a new Context + Environment per script (but “relatively” is the key word here – you may have to measure for yourself how strong the impact is exactly, if you want a precise answer). But either way, performance is probably not the most relevant question here, in particular:

In my case each script I run could have some arbitrary npm dependencies (the script will come from a path that's pulled before the embedder runs). Is it better in my case to start with a new context per run?

That probably depends on the degree of isolation you want between the scripts – for example, if one script stores something on the global object, or modifies a language built-in object like Object or JSON.parse, should the other script be able to access that variable? (That’s the amount of separation provided by different Contexts).

Currently, it’s not really possible to create multiple fully-featured Node.js Contexts for a single Environment at a given time (i.e. where you can require() stuff), but in the future, it might be. That means that Context-level isolation for things that use require() (like npm packages) would also imply Environment-level isolation. That means, for example, that the lifetime of Node.js API objects like network connections, servers, file streams, etc. are tied to the lifetime of the Environment itself.

[benjamintli]

Makes sense. In my case then I'd probably have to spin up a new environment and context per script run, since the scripts are provided by the user and should be cleaned up afterwards in case they do something funky to the global variable

[brandonros]

@addaleax

You can also run multiple scripts per Environment, that’s no problem at all. In that case, you can use the V8 Script class to compile and run individual scripts. In that case, you may want to use the overload of LoadEnvironment that takes a StartExecutionCallback callback instead, so that you have raw access to the objects that Node.js provides to you.

Can you show an example of how to run multiple scripts per Environment please?

[addaleax]

@brandonros As the quoted comment says, you use the V8 Script class in that case. https://chromium.googlesource.com/v8/v8/+/branch-heads/6.8/samples/hello-world.cc has a rough example of how that works (amongst other things).

[brandonros]

That’s for V8, aka I can’t call “require” from node.js, right?

[addaleax]

@brandonros Hence the second sentence from your quote – the LoadEnvironment overload that takes a callback gives you access to e.g. require. You can then manually pass these values to JS code in a way that you prefer.

[brandonros]

@brandonros Hence the second sentence from your quote – the LoadEnvironment overload that takes a callback gives you access to e.g. require. You can then manually pass these values to JS code in a way that you prefer.

That lets me set up an Environment, run code once, then tear it down.

I want to be able to set up an Environment, run code against it more than once, then tear it down.

Any recommendation? Thank you for your help so far. @addaleax

[addaleax]

@brandonros Yeah, but it gives you a require function that you can use to load code (e.g. do require('vm') and then use vm.runInThisContext()).

[brandonros]

@brandonros Yeah, but it gives you a require function that you can use to load code (e.g. do require('vm') and then use vm.runInThisContext()).

@addaleax I want to be able to create a Node environment from C++ but call back and forth in/out of it. aka, get a C++ function call, trigger something in the node runtime, get a result, pass it back to C++

but multiple times

aka, not just set up the enviornment and run a script once and be done

but instead, set up the environment, run a script, get a result, run another script, get another result, etc.

[addaleax]

@brandonros I understand that – can you maybe help me understand in what way my most recent comment here doesn’t help with that?

[brandonros]

Sure. I will give you a better example. I am writing a DLL. The DLL exports many functions, like this: http://www.drewtech.com/support/passthru.html

Vehicle diagnostic applications load these libraries and then FFI these symbols/functions. It's like an abstraction on USB devices.

I want DllMain (Win32) to load the node.js environment

then, the diag app will call PassThruOpen. I want PassThruOpen to go: diag app -> my DLL -> the running node.js environment

then, the diag app will call PassThruConnect. How am I supposed to route these incoming DLL calls to the running node.js environment using vm.runInThisContext()? Do you have a sample?