On Mon, Jan 4, 2016 at 9:53 PM, smaug <sm...@welho.com> wrote: > 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)...
So, the a bit more complicated part are used to dealing with the XPConnect things? I am trying to figure out a way that support > > > > 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++. > 1、I was not trying implement new things in xpcom, our company(Kingsoft) are maintaining a fork of thunderbird, and at the current time We have to re-use existing XPCOM components that already exists in the thunderbid gecko world, beyond pure html things, there is too much things we have to re-use(xpcom things), and we are facing performance problems, the mork-db and the mime-parse, they are all working in synchronous way, so I have to figure out a way to calling these components in a worker directly, so that they would not cause UI-lag in main-thread. That's all the reason why I was trying to re-implement XPConnect with js-ctypes. So that I can calling the exist components in the worker. And free the main-thread. 2、Besides these reason, another important reason, I didn't see any way(example) to use WebIDL without building xul.dll, maintain the xul.dll is a big burden for small teams (for us, about 8 developers), so even if we trying to implement WebIDL things, we need a way to building WebIDL components independently, at the current time, I didn't see any possibilities. 3、 There is an advantage of XPCOM, WebIDL seems merely for Javascript, but XPCOM seems more language-neutral, we could be able to use xpcom in Java/Python and other languages, that's looks like a advantage of XPCOM. -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 > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
