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? Cheers, David 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
