Does rquickjs consider supporting `ReentrantLock` for `Mut<T>`?

[HenryLin2000]

If I register a RustFunction to quickjs and wrap it as a method which can be called in JS (let's call it js_native_func()). If I need to call some JS engine APIs in this RustFunction, then I need to call the context.with() method for the second time (the first time is when evaluating the JS code with js_native_func()), and a "single-thread deadlock" will occur.
If ReentrantLock can be used, it seems that this problem can be solved.

[DelSkayn]

I don't understand your need to call with a second time. If a function is called from JS it is already within a with call and you should be able to obtain the Ctx type you can use to call any of the engine functions. You didn't provide an example so I don't know your specific context but with the rquickjs functions you can take Ctx as one of the parameters of your function.

Example:

use rquickjs::{Ctx, Object, Result, prelude::Func};

fn rust_create_object<'js>(ctx: Ctx<'js>) -> Result<Object<'js>> {A
    // Do something with ctx
    Object::new(ctx)
}

pub fn main() {
    let runtime = rquickjs::Runtime::new().unwrap();
    let context = rquickjs::Context::full(&runtime).unwrap();

    context.with(|ctx| {
        ctx.globals()
            .set("create_object", Func::new(rust_create_object))
            .unwrap();

        ctx.eval::<Object, _>(" create_object() ").unwrap();
    });
}

[FrankHB]

I've met exact the same problem last year. My vendorized workaround is to modify the impl of Context by adding:

	pub fn with_unlocked<F, R>(&self, f: F) -> R
    where
        F: FnOnce(Ctx) -> R,
    {
        let guard = self.0.rt.inner.lock();
        // XXX: This is crucial, in particular when `parallel` is not enabled.
        guard.update_stack_top();
        let ctx = unsafe { Ctx::new(self) };
        // !!!
	mem::drop(guard);
        f(ctx)
    }

This is certainly buggy for concurrent execution. And when parallel is enabled, the behavior will differ. I'm now working around this...

@DelSkayn Sure if ctx is totally awared by the client code. The problem is that Ctx is a Rust type so it is not easy to be passed in to JavaScript code and back to the native code without additional work of bindings. And since it is bounded by a lifetime, it is also difficult to be stored somewhere natively except by just sharing one instance in the call frame at the initial one. For instance, consider the following code:

pub fn run(entry_func: &'static dyn Fn() -> ()) {
	SOME_SINGLETON_CONTEXT.with(&|ctx: Ctx<'_>| {
		ctx.globals().set("entry_func", Function::new(ctx.clone(), entry_func))
			.expect("failed to set: entry_func");

		let _ : Value = ctx.eval(r#"entry_func()"#)
			.expect("failed to evaluate entry_func()");
	})
}

How to pass ctx to the client when the definition of entry_func is totally determined by the caller (by design)? In particular, what should I tell the client to use such API? Moreover, how to share the context among different threads? (The last is actually another headache not tightly coupled with the problem here, though...)

Additionally, I'd argue that explicit passing the context is anti-idiomatic at least in the JavaScript code. To the traditional of programming language theory, a context is mostly an implicit device in the object language. That is, in the underlying calculus, it is an abstract data struct of some "hole" to carry any interested contextual information (usually a term in term-rewriting based semantic model, corresponding to an expression or tree node in tree-based IL for contemporary PL's implementations). OTOH, enforcing the context to be explicitly passed in the object language is quite anti-intuitive for the normal users of object language, say, the JavaScript coders in this case. A canonical example of the abstraction power of implicit ("direct") style is higher order controls: with call/cc and more expressive primitives like shift/reset, the direct style of source code in a programming language can encode many computational effects implicitly, and constructs such as exception handling or asynchronous coroutines "primitives" can built upon them in pure library code; while the behaviorally equivalent "compiled" explicit CPS'd code is usually just hardly human-readable.

[DelSkayn]

pub fn run(entry_func: &'static dyn Fn() -> ()) {

Is there any reason the signature can't be pub fn run(entry_Func: &'static dyn Fn(Ctx)){? Because that would solve the issue of passing the context here.

Additionally, I'd argue that explicit passing the context is anti-idiomatic at least in the JavaScript code. To the tr...

I don't really get this section, I am not designing a language, rquickjs is a wrapper around a Javascript engine. You are going to need a pointer to the engine and you have to pass that around if you want to use the engine. This will be the case if you use the rust bindings or if you use the original C bindings. Ctx is that pointer with a lifetime added as a safety mechanism.

[FrankHB]

Is there any reason the signature can't be pub fn run(entry_Func: &'static dyn Fn(Ctx)){? Because that would solve the issue of passing the context here.

The reason to have entry_func without Ctx parameter is to have an entry that not necessarily to do with the execution of JS, i.e. it is (initially) a pure Rust function (to do some pure Rust works like initialization of some other components and set up an event loop). Then, JS is opted-in on demand, in two places: first, the caller of entry_func may insert some instrumentation code implemented in JS (before/after the call to entry_func in eval, not shown in my previous code) configurable at runtime; second, in some function called by the native implementation of entry_func, JS may be used to implement the domain logic, which may or may not share the state of the enclosing call (e.g. globalThis). The actual function entry_func pointing to is still not aware of JS in essential, so it should conceptionally have no Ctx in its signature.

I don't really get this section, I am not designing a language, rquickjs is a wrapper around a Javascript engine. You are going to need a pointer to the engine and you have to pass that around if you want to use the engine. This will be the case if you use the rust bindings or if you use the original C bindings. Ctx is that pointer with a lifetime added as a safety mechanism.

Sorry, I missed the fact that rquickjs can already make sure the ctx in the inner reentrant call is just the same one inherited implicitly from the enclosing call in the same runtime (so I can continue to eval JS entry_func() instead of being headache on figuring out what is the argument in entry_func(???)). The arguments are then only applied for the Rust functions, which should have less impacts on the client code, but still cumbersome: since there can be entry_func implementation by others and I'd teach them to use the Ctx correctly even they have nothing work to do with JS. Still, not allowing nested ctx.with calls is somewhat unintuitive.

Since I've implemented the workaround by directly modifications on Context::with and reference types, I see it may need to modify the underlying locking mechanism, so there is the valid point to prevent the changes on the semantics of current API like Context::with. Maybe there can be some variant of the context type with capability of reentrant with in parallel to the current Context?

If there is no feasible choice other than adding a Ctx parameter on entry_func, I may need one more feature to opt-in (so it won't break the old code)... This seems to work, at the cost of some engineering overhead.

[HenryLin2000]

How to pass ctx to the client when the definition of entry_func is totally determined by the caller (by design)? In particular, what should I tell the client to use such API?

I agree with @FrankHB . In fact, I have a similar context. I cannot use Ctx as a closure parameter because I need to provide an engine-independent interface to the outside world (Actually I'm using JSI, which is part of the React Native). For example, I define the type of the functions that need to be registered to JS as:
pub type MyRustFunction = &dyn Fn(&dyn Runtime, &MyParams) -> MyValue;
And the MyParams is a universal parameter type, which cannot contain Ctx