Mit freundlichen Grüßen Andreas Schlegel
Am 10.01.2014 20:27, schrieb Steve Fink: > On Fri 10 Jan 2014 01:52:55 AM PST, Andreas Schlegel wrote: >> Hello Steve, >> >> thank you for your reply. >> >> Am 09.01.2014 21:47, schrieb Steve Fink: >>> On 01/06/2014 09:25 AM, Andreas Schlegel wrote: >>>> Hello, >>>> >>>> I need the JSContext to declare JS::RootedObjects or Values. >>>> Especially for the case of WeakMap/Map/Set-Hasher I don't have the >>>> JSContext. >>>> >>>> At the moment I use the following implementation to get the JSContext >>>> (this is a code snipped of a hash-function): >>>> >>>> JSRuntime * rt = JS_GetObjectRuntime(&value.toObject()); >>>> JSContext *cx = DefaultJSContext(rt); >>>> return DefaultHasher<JSObject >>>> *>::hash(value.toObject().GetIdentityObject(cx)); >>>> >>>> If I want to change the operator== of Value.h, I cannot use the first >>>> two functions, because they aren't known and I cannot include jsapi.h >>>> because of circle include errors. >>>> >>>> Is there a better way to retrieve the JSContext from JS::Value or JSObject? >>> No, since Values and JSObjects are not associated with JSContexts. >>> JSContexts relate to control flow, and are independent of the data. >>> >>> One way to solve this would be to reimplement the JSRuntime rooters, and >>> automatically fetch the runtime from TLS. We had that before, but >>> removed it because it was such a large perf footgun. It sounds like >>> Gecko has places where it would be properly used, though, so we should >>> perhaps add it back in some form. >>> >>> AIUI, you're doing experimental work on transparent proxies. I assume >>> perf doesn't matter too much? (Must not, if you're willing to make '==' >>> way way more complex!) Then why not make operator== out of line and >>> define it in jsapi.cpp or somewhere? >> Yes I'm doing experimental work on transparent proxies, but I hope this >> gives not a really bad perf. I will evaluate it later. I try to change >> as few as possible on the program structure to increase the acceptance >> for this thematic. >> But I think you're correct and I can only define the operator outside >> JS::Value to get it to work. Is it really possible to create it in >> jsapi.cpp, because Value.h is an include in jsapi.h(-->Circle include)? > There's no cycle. jsapi.cpp includes jsapi.h includes Value.h. Sorry my mistake, I thought I have to include jsapi.h into Value.h for implementing the operator but extern is enough. > >> If I understand it correct with "JS_GetObjectRuntime" I get the Runtime >> and there is only one. > Yes > >> With "DefaultJSContext(rt)" I get the correct >> Context if only one is available or the default in an multi-threading >> application. > Contexts and threads don't have much to do with each other. If you > ignore a couple of things, a JSRuntime is always in a single thread and > all JSContexts of that runtime are in the same thread. If you have > multiple threads, you need a runtime for each, and each runtime will > use one or more of its own JSContexts. Ok, thats new for me, because I read the following from JSAPI_basics-Dokumentation: "There is a close association between contexts and threads. Simple, single-threaded applications can use a single context for everything. But each context can only do one thing at a time, so in a multithreaded application, only one thread at a time should use any given context. Such an application typically has one context per thread." But if each Thread has its own runtime, how is it possible to access variables from different threads? Because the documentation says that each "/runtime/, is the space in which the JavaScript variables, objects, scripts, and contexts used by your application are allocated". >> If I have a multi-threaded application and the object has an other >> Context as the default is this correct or not? If not how can I get the >> correct? > JSContexts are independent of data. Any context at all is fine for this > purpose (i.e., making a Rooted.) Er, well, any context associated with > the correct JSRuntime (thread), I should say. > > The fact you need a JSContext at all instead of a JSRuntime is an > efficiency hack (callers are far more likely to have a JSContext lying > around, and it's an extra dereference to get to a context's runtime.) > For any other purpose, you'd have to worry about that state of the > JSContext (is it in a request? Is there an error pending?) but for your > case none of that matters. > >>>> My sencond question is: >>>> Where is the best place for the GetIdentityObject-function? Because >>>> JSObject and most other files are also not known to Value.h. I've tried >>>> to include jsproxy.h with my function, which leads also to a circle >>>> include. >>> What types does it require? I'd kind of expect it to be declared in >>> Value.h and defined somewhere like jsproxy.cpp. >> You mean I should declarate it as extern in Value.h and implement it in >> jsproxy.cpp? > Yes > > Thanks _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
