Alternate for GetCallingContext

39 views
Skip to first unread message

madana gopal

unread,
Nov 18, 2019, 9:28:09 AM11/18/19
to v8-users
Hi,

We have case, where dynamic functions need to use same context as javascript code that calls it. GetCallingContext() is helping to achieve it, but it is marked as deprecated in code. Please let us know, do we have any alternative api. Or, do we have any way to make dynamic functions use different context, instead of global context.

Thanks.

Regards,
Madan

Ben Ernst

unread,
Nov 19, 2019, 9:23:22 AM11/19/19
to v8-users
Madan,

I'm using GetCurrentContext() for where I have an isolate but I need a context. Have a look at the comments. Does that do what you need? 

Ben

madana gopal

unread,
Nov 19, 2019, 10:17:52 AM11/19/19
to v8-users
Thanks Ben. We tried GetCurrentContext(), but it didn't worked. i.e in below piece of code in deps/v8/src/builtins/builtins-function.cc:

MaybeHandle<Object> CreateDynamicFunction(Isolate* isolate,
                                          BuiltinArguments args,
                                          const char* token) {
.  Handle<JSFunction> function;
  ................
    ASSIGN_RETURN_ON_EXCEPTION(
        isolate, function,
        Compiler::GetFunctionFromString(
            handle(target->native_context(), isolate), source,
            ONLY_SINGLE_FUNCTION_LITERAL, parameters_end_pos),
        Object);
    Handle<Object> result;
    ASSIGN_RETURN_ON_EXCEPTION(
        isolate, result,
        Execution::Call(isolate, function, target_global_proxy, 0, nullptr),
        Object);
    ........
 }

Here, dynamic Functions() are created and we want to share the context of the calling javascript to it, instead of native context. So, using GetCallingContext() helped here.

Please share your thoughts and best approach to solve this.

Thanks.

Regards,
Madan

madana gopal

unread,
Dec 2, 2019, 9:57:51 AM12/2/19
to v8-users
Any suggestions team on this?.

Thanks.

Regards,
Madan

Toon Verwaest

unread,
Dec 3, 2019, 8:34:55 AM12/3/19
to v8-users
This API was removed when V8 implemented tail calls: there's no way to guarantee that we get the right calling context.

While we could technically reintroduce something like GetCallingContext now that we don't support tail calls anyway, it might make more sense to have explicit support for context-independent accessors. We've had something like that in the past. Basically it would simply be a FunctionTemplate installed on an object that keeps the context as is (or its native context at least) when being called. Object.getOwnPropertyDescriptor would return a JSFunction from the context that accessed the property. So

// context 1
function access_from_context1(o) { return Object.getOwnPropertyDescriptor(o, "a").get }
// context 2
function access_from_context2(o) { return Object.getOwnPropertyDescriptor(o, "a").get }
access_from_context1(o) != access_from_context2(o)

Would that cover your needs? The API change would basically simply be a flag on FunctionTemplates used as lazy accessors indicating that they shouldn't swap the context.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/ae49be52-cf16-4112-8181-02e14b005780%40googlegroups.com.

madana gopal

unread,
Jan 22, 2020, 11:37:19 PM1/22/20
to v8-users
Thanks, sorry for delayed reply.

const foreignFunction = console.constructor.constructor;

Above is the function call and it is returning the  function in native context and not from calling context. So, later when we execute the function foreignFunction(), it is getting executed in native context. Can this be prevented with the patch you suggested?. Please clarify about what is the flag to prevent swap of context and where to do it?.

Please correct if any of understanding is wrong.

Thanks.

Regards,
Madan
Reply all
Reply to author
Forward
0 new messages