Out of curiosity, how will this interact with nsCOMPtr thread-safe (or
thread-unsafe) refcounting?

Also, in code I have seen, `NS_IsMainThread` is used mainly for
assertion checking. I *think* that the semantics you detail below will
work, but do you know if there is a way to make sure of that?

Also, I had the impression that Quantum DOM scheduling made JS event
loop spinning unncessary. Did I miss something?


On 5/19/17 1:38 AM, Bill McCloskey wrote:
> Hi everyone,
> One of the challenges of the Quantum DOM project is that we will soon have
> multiple "main" threads [1]. These will be real OS threads, but only one of
> them will be allowed to run code at any given time. We will switch between
> them at well-defined points (currently just the JS interrupt callback).
> This cooperative scheduling will make it much easier to keep our global
> state consistent. However, having multiple "main" threads is likely to
> cause confusion.
> To simplify things, we considered trying to make these multiple threads
> "look" like a single main thread at the API level, but it's really hard to
> hide something like that. So, instead, we're going to be transitioning to
> APIs that try to avoid exposing threads at all. This post will summarize
> that effort. You can find more details in this Google doc:
> https://docs.google.com/document/d/1MZhF1zB5_dk12WRiq4bpmNZUJWmsIt9OTpFUWAlmMyY/edit?usp=sharing
> [Note: I'd like this thread (and the Google doc) to be for discussing
> threading APIs. If you have more general questions about the project,
> please contact me personally.]
> The main API change is that we're going to make it a lot harder to get hold
> of an nsIThread for the main thread. Instead, we want people to work with
> event targets (nsIEventTarget). The advantage of event targets is that all
> the main threads will share a single event loop, and therefore a single
> nsIEventTarget. So code that once expected a single main thread can now
> expect a single main event target.
> The functions NS_GetMainThread, NS_GetCurrentThread, and
> do_Get{Main,Current}Thread will be deprecated. In their place, we'll
> provide mozilla::Get{Main,Current}ThreadEventTarget. These functions will
> return an event target instead of a thread.
> More details:
> NS_IsMainThread: This function will remain pretty much the same. It will
> return true on any one of the main threads and false elsewhere.
> Dispatching runnables: NS_DispatchToMainThread will still work, and you
> will still be able to dispatch using Get{Main,Current}ThreadEventTarget.
> From JS, we want people to use Services.tm.dispatchToMainThread.
> Thread-safety assertions: Code that used PR_GetCurrentThread for thread
> safety assertions will be converted to use NS_ASSERT_OWNINGTHREAD, which
> will allow code from different main threads to touch the same object.
> PR_GetCurrentThread will be deprecated. If you really want to get the
> current PRThread*, you can use GetCurrentPhysicalThread, which will return
> a different value for each main thread.
> Code that uses NS_GetCurrentThread for thread safety assertions will be
> converted to use nsIEventTarget::IsOnCurrentThread. The main thread event
> target will return true from IsOnCurrentThread if you're on any of the main
> threads.
> Nested event loop spinning: In the future, we want people to use
> SpinEventLoopUntil to spin a nested event loop. It will do the right thing
> when called on any of the main threads. We'll provide a similar facility to
> JS consumers.
dev-platform mailing list

Reply via email to