Closed Bug 1046275 Opened 8 years ago Closed 8 years ago

Concurrency issues in Android WebRTC code

Categories

(Core :: WebRTC: Audio/Video, defect)

All
Android
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla34

People

(Reporter: gcp, Assigned: gcp)

Details

Attachments

(1 file)

https://bugzilla.mozilla.org/show_bug.cgi?id=1039898#c94

hat said, I think we agree there's 2 issues we need to deal with:

1) mCaptureRotation should be volatile, to *ensure* the cross-thread
writes are eventually seen.

2) The native code can call stopCapture and we can simultaneously get
onPause. onPause checks for the camera being null before calling
stopCapture (and sets mResumeCapture), but the other call can already be
in stopCapture at that point, and nulling camera. That would produce bug
1042689.

Whether mCaptureWidth,H,MinFps,MaxFps have a similar possibility depends
on whether onResume can race with startCapture. I'm not clear if the
native call to startCapture can happen *before* onResume is called
because onResume implies we're paused, but we should probably make
onResume synchronized regardless.
Also get rid of that inner class so I can keep my privates. I'm fond of them.
Attachment #8466211 - Flags: review?(rnewman)
Comment on attachment 8466211 [details] [diff] [review]
Patch 1. Fix concurrency issues

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

lgtm!
Attachment #8466211 - Flags: review?(rnewman) → review+
https://hg.mozilla.org/mozilla-central/rev/f8785a729a51
Assignee: nobody → gpascutto
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.