Open Bug 1271538 Opened 5 years ago Updated 5 years ago

DriverCrashGuard should be usable outside the main thread

Categories

(Core :: Graphics, defect, P4)

defect

Tracking

()

Tracking Status
e10s + ---

People

(Reporter: jya, Unassigned)

References

Details

(Keywords: feature, Whiteboard: gfx-noted)

Right now, DriverCrashGuard::Initialize() will simply return early if it detected that it's not called on the main thread.

  // Using DriverCrashGuard off the main thread currently does not work. Under
  // e10s it could conceivably work by dispatching the IPC calls via the main
  // thread. In the parent process this would be harder. For now, we simply
  // exit early instead.
  if (!NS_IsMainThread()) {
    return;
  }

Glancing at the code, it seems that if e1s0s is enabled and we are in the content process, the only worry is RecvBeginDriverCrashGuard to ensure access to ContentParent::mDriverCrashGuard is thread-safe.

DriverCrashGuard::ActivateGuard does nothing if we're in the content process.
tracking-e10s: --- → ?
Whiteboard: gfx-noted
I don't see why we would track this for E10S.  Is there a particular example crash guard we have in mind?
Keywords: feature
(In reply to Jean-Yves Avenard [:jya] from comment #0)
> Right now, DriverCrashGuard::Initialize() will simply return early if it
> detected that it's not called on the main thread.
> 
>   // Using DriverCrashGuard off the main thread currently does not work.
> Under
>   // e10s it could conceivably work by dispatching the IPC calls via the main
>   // thread. In the parent process this would be harder. For now, we simply
>   // exit early instead.
>   if (!NS_IsMainThread()) {
>     return;
>   }
> 
> Glancing at the code, it seems that if e1s0s is enabled and we are in the
> content process, the only worry is RecvBeginDriverCrashGuard to ensure
> access to ContentParent::mDriverCrashGuard is thread-safe.
> 
> DriverCrashGuard::ActivateGuard does nothing if we're in the content process.

Right, IPC isn't threadsafe so we'd have to do something else to make sure the message arrives synchronously. But before thinking about it too hard we should answer comment #1.
Priority: -- → P4
(In reply to Milan Sreckovic [:milan] from comment #1)
> I don't see why we would track this for E10S.  Is there a particular example
> crash guard we have in mind?

In media, we check that no dxva crash occurred and disable hardware acceleration if a crash occurred. We've had issues related to the timing of when the media stack is being initialised so we are redoing some stuff. One of them is allowing the media decoders to be initialised/created outside the main thread.

When we do so, the check if dxva didn't crash before will no longer work.
You need to log in before you can comment on or make changes to this bug.