On Aug 29, 11:22 am, Benjamin Smedberg <[EMAIL PROTECTED]> wrote: > Jason Orendorff wrote: > > * Add thread-safety to MMgc using the Spidermonkey request model. > > This is the part that has me extremely worried. We would have to propagate > the request model throughout all of our XPCOM code, which is a very tricky > task. As I understand it, the invariants for requests are: > > 1) GC references may change only within a request > 2) blocking (or long-running) activity should not take place within a request > > I think that keeping track of whether we're currently in a request would be > a major headache.
I am not too worried. I think I see how this is going to work. All threads will be in a request all the time, except when doing blocking I/O or CPU-bound, non-GC-touching stuff. You'll have to suspend the request before doing that kind of thing, and resume it afterwards. I imagine we'll have a C++ object that knows how to do this. (Like nsAutoLock. "nsAutoSuspendRequest", maybe.) Finding those places would be the only hard part. But if you miss one, it should be *real* easy to spot and debug. Firefox will seem to hang. You'll attach a debugger, and all threads will be sitting in MMgc::waitForGC except for one, which will be blocked on DNS or compositing video buffers. > Are we sure that we want to get into the "revamp XPCOM" game just to get > going with fast-path DOM? The approach you mention in comment 14 approach C > makes a lot of sense, without rewriting all of XPCOM: > [...] Well, my short-term plans are still incremental. But this conversation has been dormant since December. I really want to know the long-term plan, for both short-term and long-term reasons. -j _______________________________________________ dev-tech-xpcom mailing list dev-tech-xpcom@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-xpcom
