UseSharedImageInOOPVDProcess: ImportSharedImage when decoder destructs [chromium/src : main]
Kramer Ge (Gerrit)
Kramer Ge voted and added 1 comment![]( "Open in Gerrit")
Votes added by Kramer Ge
| Commit-Queue | +1 |
Related details
- Vasiliy Telezhnikov
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Vasiliy Telezhnikov (Gerrit)
Vasiliy Telezhnikov added 1 comment![]( "Open in Gerrit")
sii->ImportSharedImage(token_to_image.second->Export());This is async operation, if the utility process will be killed before this finish, we won't be able to add the ref.
Do you know what keeps utility process alive? (i.e destruction of what object kills the process)?
Related details
- Colin Blundell
- Kramer Ge
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kramer Ge (Gerrit)
Kramer Ge added 1 comment![]( "Open in Gerrit")
sii->ImportSharedImage(token_to_image.second->Export());This is async operation, if the utility process will be killed before this finish, we won't be able to add the ref.
Do you know what keeps utility process alive? (i.e destruction of what object kills the process)?
`~MojoVideoDecoder` closes the mojo IPC channel, which through destruction of `MojoVideoDecoderService` in gpu process, leads to destruction of `OOPVideoDecoderService` in OOPVD process, `RenderProcessHostImpl` keeps track of the `OOPVideoDecoderService` by maintaining a list of `video_decoder_trackers_` [[1]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.h;l=1510;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1). When there's 0 `tracker`s left it will kick off a timer to shutdown the oopvd process [[2]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.cc;l=2466;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1).
Since here `ImportUnownedSharedImages()` is called before `~MojoVideoDecoder` completes, and given 3s timer, this should be able to complete before utility process dies. I'm uncertain the if the IPCs between GpuChannel communication vs media mojo channel destruction are sequenced, I assume they are going through the same IO task posting.
Related details
- Colin Blundell
- Vasiliy Telezhnikov
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kramer Ge (Gerrit)
Kramer Ge added 1 comment![]( "Open in Gerrit")
sii->ImportSharedImage(token_to_image.second->Export());Kramer GeThis is async operation, if the utility process will be killed before this finish, we won't be able to add the ref.
Do you know what keeps utility process alive? (i.e destruction of what object kills the process)?
`~MojoVideoDecoder` closes the mojo IPC channel, which through destruction of `MojoVideoDecoderService` in gpu process, leads to destruction of `OOPVideoDecoderService` in OOPVD process, `RenderProcessHostImpl` keeps track of the `OOPVideoDecoderService` by maintaining a list of `video_decoder_trackers_` [[1]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.h;l=1510;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1). When there's 0 `tracker`s left it will kick off a timer to shutdown the oopvd process [[2]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.cc;l=2466;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1).
Since here `ImportUnownedSharedImages()` is called before `~MojoVideoDecoder` completes, and given 3s timer, this should be able to complete before utility process dies. I'm uncertain the if the IPCs between GpuChannel communication vs media mojo channel destruction are sequenced, I assume they are going through the same IO task posting.
Per offline discussion I looked into how `mojom::VideoFrameHandleReleaser` and if it's possible to keep `mojom::VideoDecoderTracker` alive to prevent process shutdown. It turns out to be more complicated:
After `~MojoVideoDecoder`, Renderer can still send `VideoFrame` releases via `mojom::VideoFrameHandleReleaser` to receiver in gpu process where `OOPVideoDecoder` will forward to the receiver in utility process. Sadly this `mojom::VideoFrameHandleReleaser` chain is broken in the gpu process because `OOPVideoDecoder` owns the `releaser` remote to the utility process, and is destroyed with renderer's decoder endpoint.
Kramer Ge (Gerrit)
Kramer Ge voted and added 1 comment![]( "Open in Gerrit")
Votes added by Kramer Ge
| Commit-Queue | +1 |
1 comment
sii->ImportSharedImage(token_to_image.second->Export());Kramer GeThis is async operation, if the utility process will be killed before this finish, we won't be able to add the ref.
Do you know what keeps utility process alive? (i.e destruction of what object kills the process)?
Kramer Ge`~MojoVideoDecoder` closes the mojo IPC channel, which through destruction of `MojoVideoDecoderService` in gpu process, leads to destruction of `OOPVideoDecoderService` in OOPVD process, `RenderProcessHostImpl` keeps track of the `OOPVideoDecoderService` by maintaining a list of `video_decoder_trackers_` [[1]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.h;l=1510;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1). When there's 0 `tracker`s left it will kick off a timer to shutdown the oopvd process [[2]](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_process_host_impl.cc;l=2466;drc=ad0b5be27291850e9e7dd78b33fdf31949168d50;bpv=0;bpt=1).
Since here `ImportUnownedSharedImages()` is called before `~MojoVideoDecoder` completes, and given 3s timer, this should be able to complete before utility process dies. I'm uncertain the if the IPCs between GpuChannel communication vs media mojo channel destruction are sequenced, I assume they are going through the same IO task posting.
Per offline discussion I looked into how `mojom::VideoFrameHandleReleaser` and if it's possible to keep `mojom::VideoDecoderTracker` alive to prevent process shutdown. It turns out to be more complicated:
After `~MojoVideoDecoder`, Renderer can still send `VideoFrame` releases via `mojom::VideoFrameHandleReleaser` to receiver in gpu process where `OOPVideoDecoder` will forward to the receiver in utility process. Sadly this `mojom::VideoFrameHandleReleaser` chain is broken in the gpu process because `OOPVideoDecoder` owns the `releaser` remote to the utility process, and is destroyed with renderer's decoder endpoint.
Post PS#4, I prolonged the utility process and video_frame handle releaser lifetime.
The caveat for this approach is that utility process can't crash before proper release as it is the sole owner of SI.
Marking as done.
Related details
- Colin Blundell
- Vasiliy Telezhnikov
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |