Open Bug 1391861 Opened 7 years ago Updated 2 years ago

Make WebRTC code work with Quantum DOM scheduling

Categories

(Core :: WebRTC, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: billm, Unassigned)

References

Details

I'm still not sure how to do this, so I'm filing so we can discuss it. The patch I have right now just wraps this code in an #if 0:
http://searchfox.org/mozilla-central/rev/8d084472a955c9ef0f523c743cbad2460efd7688/media/webrtc/trunk/webrtc/base/thread_checker_impl.cc#26-30

Presumably that won't fly. There are a couple questions I have:

1. If we need to modify the non-Mozilla WebRTC code, how can we do that?
2. How should I modify the assertion? I guess the ideal way to handle it would be to use our own Mozilla assertions instead. But that would only work if this code gets linked into libxul and can somehow access Mozilla headers. If that doesn't work, then I could re-implement our assertions inside the WebRTC code I guess.
Flags: needinfo?(rjesup)
(In reply to Bill McCloskey (:billm) from comment #0)
> I'm still not sure how to do this, so I'm filing so we can discuss it. The
> patch I have right now just wraps this code in an #if 0:
...
> Presumably that won't fly. There are a couple questions I have:

Correct (and even if it did work, which it almost might, it would void all the on-correct-thread checks which would catch any threading mistakes we made).

> 1. If we need to modify the non-Mozilla WebRTC code, how can we do that?

We can, though if we can't get them to accept it upstream we have to carry the patch.  We're trying to reduce the patches we carry, not increase them -- but we can.

For something specific to mozilla (not a fix to the code), #ifdef WEBRTC_MOZILLA_BUILD can be used.  We prefer to avoid it (especially mozilla headers), but that's ok.  See also build/gyp.mozbuild, and media/webrtc/moz.build (and build_with_mozilla in the .gyp/.gypi files within media/webrtc/trunk/webrtc).

> 2. How should I modify the assertion? I guess the ideal way to handle it
> would be to use our own Mozilla assertions instead. But that would only work
> if this code gets linked into libxul and can somehow access Mozilla headers.
> If that doesn't work, then I could re-implement our assertions inside the
> WebRTC code I guess.

This code is linked into libxul.  We could access mozilla headers (under #ifdef per above) if we must (so far we don't).

If the pseudoMainThread satisfies the reasons for the CalledOnValidThread() being used (which mostly (entirely??) is used to avoid needing locks so long as all accesses to something are on the same thread), then you could check if we're on MainThread when we save the thread, and when CalledOnValidThread is called, if it was MainThread use the NS_IsMainThread method instead of comparing thread ptrs.  I have some small concern this would hurt perf a little, but probably not much especially if we're careful.

something like "if (was_main_thread_) { return NS_IsMainThread(); } else { return IsThreadRefEqual(current_thread, valid_thread_); }"
Flags: needinfo?(rjesup)
Rank: 15
Priority: -- → P1
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.