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. > 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. > 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 _______________________________________________ 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
