On Sat, Jan 11, 2014 at 6:52 PM, Andreas Schlegel <
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);
_______________________________________________
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

Reply via email to