Am 11.01.2014 19:28, schrieb Till Schneidereit: > On Sat, Jan 11, 2014 at 6:52 PM, Andreas Schlegel > <schlegel.andr...@gmail.com <mailto:schlegel.andr...@gmail.com>> wrote: > >> >> 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? >> >> >> Regardless of the threading stuff, objects don't belong to >> contexts at all. They belong to compartments and can only be >> accessed if that compartment has been entered. To refer to >> objects from other compartments, a cross-compartment wrapper has >> to be created. I would recommend dealing with that after your >> changes work within a single global object. > Can you explain me a little bit? I understand that the > compartments are used to create multiple memory heaps for > increasing perf of the garbage collector and the wrappers are used > to touch objects from another compartment. > But I don't understand the direct relation to my work. I need the > Context to create RootedValues/Objects and for calling other > functions which needs the context. I found only a function which > gives me the default context over the runtime of an object, but > the object's don't belong to the context :-). It's a little bit > confusing to me. > > > Objects don't belong to contexts, ever. A context is for storing > things relevant to the current control flow state, not to data in the > VM. At some point, contexts will be removed entirely and the state > they now hold will be kept on the runtime. For now, using the default > context should be fine. > > The compartments will become relevant if and when you start comparing > objects from different globals. I don't know if that's required at > all. If not, you shouldn't have to worry about compartments at all, as > your function will be invoked with the correct compartment already > entered. For clarity's sake, here's an example script for which > compartments have to be pushed on and popped from the stack: > > var global = newGlobal(); > evalcx('var obj = {foo:"bar"}', global); > print(global.obj.foo); Ok, I understand. At the moment I've changed the functions LooselyEqual and StrictlyEqual of the Interpreter. The comparism with "==" and "===" is mostly done there if I'm correct. My tests show that only comparing in loops with more than 10 iterations are done someone else, because of JIT optimization. The available comparism tests for globals are all passed.
Can you give me a test example to test if my code get into trouble? _______________________________________________ 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
