On 01/03/2016 06:55 PM, David Rajchenbach-Teller wrote:
Well, XPConnect is designed for the main thread, and many of the things
it does assume that everything takes place on the main thread.
An example, from the topic of my head: whenever objects cross between
JavaScript and C++ through XPConnect, they need to be retained in
hashtables to preserve unicity, etc. For performance reasons, these
hashtables are not protected against concurrent access.
Indeed. Which is why he is thinking to re-implement xpconnect for workers using
js-ctypes, no?
(personally I'd try to avoid xpconnect as much as possible and rather try to
figure out how to make
the webidl bindings usable for whatever use case we're talking about here.)
Another example: JavaScript objects can point towards C++ objects and
vice-versa. The garbage-collector (well, the cycle-collector) needs to
walk the graph in specific ways to get rid of possible cycles that
involve both C++ and JS.
This happens in workers too.
The worker's implementation of the
cycle-collector is much simpler (and quite different) than the main
thread's,
Not really. Cycle collector is exactly the same (CycleCollectorRuntime is a bit
more complicated in main thread)...
since it doesn't need to handle XPConnect.
...XPConnect just adds couple of extra js value containers to trace. Not at all
that different
to JSHolder hashtable which is used also in workers.
XPCWrappedJS is possibly the weirdest part of xpconnect from CC/GC point of
view, given that it
implements also weakreference handling.
But anyhow, I would certainly try to avoid any new xpconnect usage and try to
figure out how to utilize
webidl. Webidl can express APIs in more JS-friendly way and in Gecko case also
the C++ side is way simpler
(and faster) than implementing idl interfaces in C++.
-Olli
> Mixing both
accidentally can lead to unpredictable results.
Oh, and XPConnect pointers can simply not be dereferenced from worker
threads. Attempting to do so will crash libxul by design to avoid accidents.
etc.
Cheers,
David
On 03/01/16 17:45, 罗勇刚(Yonggang Luo) wrote:
On Mon, Jan 4, 2016 at 12:35 AM, David Rajchenbach-Teller
<dtel...@mozilla.com <mailto:dtel...@mozilla.com>> wrote:
Accessing XPCOM in a worker will most likely break the garbage-collector
in novel and interesting ways, so I don't suggest heading in that
direction.
I'd like to hear more information about that,
For example, if I setting a finalize for each XPCOM instance
Object(javascript), when the Object's is GCed, then I release
the xpcom instance, is that would not break the garbage-collector?
Or we have other problems about garbage-collector, I am interested in that.
Cheers,
David
On 03/01/16 17:24, 罗勇刚(Yonggang Luo) wrote:
> So that we could be able to access xpcom in worker.
> And we could be able to implement thunderbird new msg protocol in
pure
> javascript
>
> On Sun, Jan 3, 2016 at 11:09 PM, Josh Matthews
<j...@joshmatthews.net <mailto:j...@joshmatthews.net>>
> wrote:
>
>> What is the motivation for this work?
>>
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
<mailto:dev-platform@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
