Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: object (and function?) handle #18

Open
wyozi opened this issue Jul 28, 2020 · 0 comments
Open

Idea: object (and function?) handle #18

wyozi opened this issue Jul 28, 2020 · 0 comments

Comments

@wyozi
Copy link
Collaborator

wyozi commented Jul 28, 2020

Hi! While I've gotten used to storing everything in ducc.globals(), I still get a bit annoyed at the whole retrieve everything from globals every time. For instance, for many calls crossing the Rust<->JS boundary I'll have to do something like ducc.globals().get("namespace").get("library").get("_refs").get(index).

However, I got an idea for a potential way to kind of store references to Duktape for faster and nicer retrieval, without sacrificing any safety guarantees. Basically, it'd be a handle type looking something like this:

#[derive(Clone)]
struct ObjectHandle {
  rc: Rc<ffi::duk_uarridx_t>
}
impl ObjectHandle {
  pub fn get_object(ducc: &Ducc) -> Object {
    // return object from heap stash
  } 
}

and API for retrieving an ObjectHandle from an Object somewhere.

Some practical concerns would be making sure that GC doesn't remove our object when we hold a handle (but is able to if we don't), which depends on Duktape's support for it. One scary bit is Drop for ObjectHandle; how can we inform Duktape that it's okay to GC the referenced object without access to &Ducc? Maybe a drop_object_reference(&Ducc) that must be called before Drop or it will panic.

The benefits of this approach would be the ability to keep a reference certain objects without caring about what is happening in the JS world, and I think the ergonomics of using it are better than the global referencing as well. If this works, it could be extended to FunctionHandle etc as well.

Does this sound like a viable/safe idea? If it turns out well, maybe the same approach would work with Mini-V8 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant