Memory and file system for current sessions

[jeroen]

I have a few questions about running webR in a long running node webserver:

• If I start multiple R istances by running const session = new x.WebR() for each incoming http request on the server, do these sessions interfere with each other? Or is each WebR instance independent?
• How do I completely destroy and free such an R instance, including its Shelter and all objects? Does it happen automatically when the object that was instantiated from new x.WebR() goes out of scope? Can I manually destroy it to immediately release all memory?
• Is the virtual file system shared between R instances?

To illustrate, below a simple NodeJS script, that runs the same code in 5 parallel R sessions:

const x  = require("@r-wasm/webr");

for (i in [1,2,3,4,5]) {
  const session = new x.WebR();
  session.init().then(function(){
    console.log("Session started!")
    session.evalR(`pi <- pi*2; pi`).then(function(obj){
      obj.toArray().then(function(data){
        console.log(data)
      });
    });
  });
}

[georgestagg]

So far, our main focus and goals with the development of webR have been in the context of running R locally within a web browser, rather than on a server. As such, starting and stopping many instances of webR has not yet been well tested by us. In the browser environment, our assumption has been that one (or a few at most) webR instances will be created early in an application's execution cycle and then used throughout, with tools such as R environments used to isolate execution where required.

Nevertheless, things should work in a node webserver. Though I am unsure of the performance penalty of starting and stopping many webR instances. My gut feeling is that it is high, probably too high to start a new instance for every HTTP request.

do these sessions interfere with each other? Or is each WebR instance independent?

Each webR instance will start a new JavaScript worker thread wherein the actual R wasm binary is executed. As such, they are largely independent. They should not interfere with one another.

How do I completely destroy and free such an R instance

WebR.close() will close the established communication channel and stop the webR worker thread. At this point, all memory allocated in the R wasm process itself should be reclaimed by the JavaScript garbage collector. The webR instance should not be used after calling close(), promises will not resolve.

For the remaining infrastructure on the main thread, once the webR instance goes out of scope I believe it should also be reclaimed by the JavaScript garbage collector. I have not tested this in detail. In addition, one must be careful to destroy any other asynchronous infrastructure that has been setup up, such as any infinite async loop message handling. In fact, perhaps an output message should be sent as the worker is destroyed for this purpose.

Is the virtual file system shared between R instances?

No. For technical reasons, we are currently quite limited in what we can do with the webR virtual filesystem. See #56 for details. In theory, Emscripten's PROXYFS could be used to share files between webR instances, but I have not experimented with this yet and there is currently no code in webR to facilitate that use case.

[jeroen]

Thank you!