Enforce that MDSM state changes only happen on the state machine task queue

RESOLVED FIXED in Firefox 39

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

unspecified
mozilla39
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Assignee)

Description

4 years ago
Doing it any other way is totally insane. Once bug 1136873 lands I think we can fix things up so that this invariant holds.
(Assignee)

Updated

4 years ago
Blocks: 1146482
(Assignee)

Updated

4 years ago
Depends on: 1136827
(Assignee)

Comment 3

4 years ago
Created attachment 8582860 [details] [diff] [review]
Part 1 - Make MDSM::Shutdown happen on the state machine thread. v1
Attachment #8582860 - Flags: review?(matt.woodrow)
(Assignee)

Comment 4

4 years ago
Created attachment 8582861 [details] [diff] [review]
Part 2 - Make MDSM::StartBuffering happen on the state machine thread. v1
Attachment #8582861 - Flags: review?(matt.woodrow)
(Assignee)

Comment 5

4 years ago
Created attachment 8582862 [details] [diff] [review]
Part 3 - Assert state machine thread for SetState. v1

We assert in CheckInDecodeComplete as well for good measure, since that's the
last caller of SetState that doesn't already assert it.
Attachment #8582862 - Flags: review?(matt.woodrow)
Comment on attachment 8582861 [details] [diff] [review]
Part 2 - Make MDSM::StartBuffering happen on the state machine thread. v1

Review of attachment 8582861 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/MediaDecoder.cpp
@@ +1498,5 @@
>    if (mResource) {
>      mResource->Resume();
>    }
>    if (aForceBuffering) {
>      ReentrantMonitorAutoEnter mon(GetReentrantMonitor());

Do we still need this monitor? We should be able to read/write |mDecoderStateMachine| on the main thread without the monitor.

@@ +1502,5 @@
>      ReentrantMonitorAutoEnter mon(GetReentrantMonitor());
>      if (mDecoderStateMachine) {
> +      RefPtr<nsRunnable> r =
> +        NS_NewRunnableMethod(mDecoderStateMachine, &MediaDecoderStateMachine::StartBuffering);
> +      mDecoderStateMachine->TaskQueue()->Dispatch(r.forget());

I would prefer to do the dispatch inside StartBuffering() to hide the details about threading model employed by MDSM. As far as MediaDecoder can see, MediaDecoderStateMachine::StartBuffering() should be a thread-safe function.
Attachment #8582861 - Flags: feedback+
(Assignee)

Comment 7

4 years ago
Created attachment 8582880 [details] [diff] [review]
Part 1 - Make MDSM::Shutdown happen on the state machine thread. v2
Attachment #8582860 - Attachment is obsolete: true
Attachment #8582860 - Flags: review?(matt.woodrow)
Attachment #8582880 - Flags: review?(jwwang)
(Assignee)

Comment 8

4 years ago
Created attachment 8582881 [details] [diff] [review]
Part 2 - Make MDSM::StartBuffering happen on the state machine thread. v2
Attachment #8582861 - Attachment is obsolete: true
Attachment #8582861 - Flags: review?(matt.woodrow)
Attachment #8582881 - Flags: review?(jwwang)
(Assignee)

Comment 9

4 years ago
Comment on attachment 8582862 [details] [diff] [review]
Part 3 - Assert state machine thread for SetState. v1

In general, feel free to do a drive-by r+ on state machine patches. :-)
Attachment #8582862 - Flags: review?(matt.woodrow) → review?(jwwang)
Attachment #8582880 - Flags: review?(jwwang) → review+
Attachment #8582881 - Flags: review?(jwwang) → review+
Attachment #8582862 - Flags: review?(jwwang) → review+
(Assignee)

Comment 10

4 years ago
Created attachment 8582898 [details] [diff] [review]
Part 4 - Dispatch all audiosink notifications asynchronously. v1

Per jww's suggestion.
Comment on attachment 8582898 [details] [diff] [review]
Part 4 - Dispatch all audiosink notifications asynchronously. v1

Review of attachment 8582898 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. Btw, MediaDecoder::UpdatePlaybackOffset() can now assert instead of acquiring the monitor. Stricter check makes it less likely to go unexpected.
Attachment #8582898 - Flags: review+
(Assignee)

Updated

4 years ago
Blocks: 1148571
(Assignee)

Updated

4 years ago
Depends on: 1144519
(Assignee)

Comment 12

4 years ago
So I did a try push of all of these patches: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d40c2e06cd66

There was one failure in test_loop.html, which I confirmed to be caused by the topmost patch:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5b1b04b6ad68
https://treeherder.mozilla.org/#/jobs?repo=try&revision=855887ee7041

I split the topmost patch out into bug 1148571, and am going to push the rest of the patches here.
(Assignee)

Comment 13

4 years ago
(the topmost patch was an extra "nice to have" suggestion by jww, and not really intrinsic to this bug to begin with)
https://hg.mozilla.org/mozilla-central/rev/18af605c42d2
https://hg.mozilla.org/mozilla-central/rev/954ec67d86f4
https://hg.mozilla.org/mozilla-central/rev/e5c5a0f31dbe
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.