Best way to capture v8::Value types through the FFI?

[tristanzander]

I apologize with this question mixing concepts from many crates from denoland, but the issue does seem to originate with the Deno CLI runtime itself.

Context

I am building an edge function handler w/ Deno that calls a custom v8 runtime sandbox with code that I provide through API. The edge function handler runs on the latest Deno CLI, whereas the sandbox runs on a custom runtime built on deno_core with unique setup and security constraints.

Problem

From the edge function gateway, I want to be able to send the Request object from the gateway instance to the newly spawned sandbox instance. I know I can pass any v8::Value to the sandboxed runtime, but I don't quite know how to get it from the FFI. I have come up with the following two ideas:

Possible Solution 1

I know I can receive objects as a *const c_void through the FFI, and this can be directly cast to an External value object using rusty_v8::External::new(scope, ptr). The better question is should it be done this way? I am aware that the scope does not come from the same v8 instance as the variable itself lives in, but I have at least guaranteed that the object will remain alive until the new runtime finishes execution.

Possible Solution 2

While I don't think it's currently possible, being able to register a deno_core::extension! dynamically through a dynamic library would be an easy solve for this issue. An op would potentially be able to retrieve the v8::Value and currently executing runtime easily and manage the sandboxed runtime. However, I don't think it's currently possible to register an op dynamically since plugins were removed.

Which would be the better option? I'm curious to see what you all think.

[tristan-zander]

Turns out that this isn't possible. You can't pass a pointer to a v8 object in the ffi, so this has to be done by an op