1038337 - GMP plugins do a DISPATCH_SYNC to the GMP thread from xpcom-shutdown

Status: RESOLVED FIXED

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

Description

[Randell Jesup [:jesup] (needinfo me)]

+++ This bug was initially created as a clone of Bug #1033522 +++

There's concern that the MainThread should never wait on the GMP thread; right now in the xpcom-shutdown observer for GMP it does a DISPATCH_SYNC to the GMP thread so it can save off data.  

Perhaps this can be time-limited/asynchronous?  We need to make sure we don't continue to use the disk too late in shutdown.

Comment 1

[Benjamin Smedberg]

Couple questions here:

http://hg.mozilla.org/mozilla-central/annotate/340b19c14d3d/content/media/gmp/GMPService.cpp#l133 is the shutdown call I see. I'm not sure why this needs to be synchronous at all. Note that we've already shut down the profile, so it would be illegal to persist any profile data anyway. It looks like we're only doing this cleanup to avoid leaks.

So it seems to me that this could be asynchronous without any ill effects.

Also DISPATCH_SYNC does spin the event loop, so I don't actually think there's any chance of a deadlock from the SyncRunnable methods in the other direction. SyncRunnable would always win the race and nest.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

I and/or cpearce will revise this to kick off shutdown earlier

Comment 3

[Benjamin Smedberg]

Why do we need to shut down earlier? Is there persistent state related to this?

Comment 4

[Chris Peterson [:cpeterson]]

These bugs are fit and finish issues that might block EME uplift to Aurora.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.