Class GpuJpegDecodeAcceleratorHost [1] owns a 
GpuJpegDecodeAcceleratorHost::Receiver instance |receiver_| that receives 
messages on a thread (IO Thread) different from the thread that the 
GpuJpegDecodeAcceleratorHost instance is operated on.

In order to support synchronous shutdown via its destructor, the destructor of
GpuJpegDecodeAcceleratorHost currently has to block while waiting for a round 
trip to the IO Thread. This design is problematic [2], because of at least two 
things:
1.) It blocks threads.
2.) It relies on the assumption that a round trip to the IO thread always 
succeeds. But this may not be the case during program shutdown, when the IO 
thread no longer accepts new tasks.

A clean solution would be to change the API of the class to expose a method for 
shutdown that runs asynchronously instead of using the destructor for shutdown.
This design change has to ripple up to the using classes, such that the 
continuation work that requires the shutdown to be complete does not get 
scheduled before the asynchronous shutdown is complete.

[1] https://cs.chromium.org/chromium/src/media/gpu/ipc/client/gpu_jpeg_decode_accelerator_host.h?dr=CSs&l=34
[2] https://codereview.chromium.org/2783273002/