The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2d0e75a06d24ff78139649b12b245e447f62f518

commit 2d0e75a06d24ff78139649b12b245e447f62f518
Author: Andres Calderon Jaramillo <andrescj@chromium.org>
Date: Fri Jun 08 23:01:08 2018

JDA unit tests: call the JDA destructor in the right thread.

This CL modifies the JDA unit tests to call the JpegDecodeAccelerator
destructor in the correct thread when the JpegClient gets destroyed.

The strategy is to destroy the JpegClient in the thread in which the
JpegDecodeAccelerator is created. To do so, we use a ScopedClosureRunner
which posts a task to the appropriate thread to delete the JpegClient
instance. This causes its decoder_ member to be deleted in that thread
as well. We must be careful with the order of destruction though: the
JpegClient cannot be destroyed until all the tasks posted by decoder_ in
a different thread spawned by decoder_ have finished. The destructor of
decoder_ should not exit until that happens. Also, notice that now,
JpegClient takes ownership of the ClientStateNotification passed in its
constructor. This is because we can't let the ClientStateNotification
die before decoder_: for example, suppose we post a task to delete the
JpegClient as described above. It is still possible that there are
pending tasks created by decoder_ that require the use of the
ClientStateNotification instance.

Bug:  850822 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I9c2b16676e903fb229232bec9e4b25fe0a74f724
Reviewed-on: https://chromium-review.googlesource.com/1091598
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565768}
[modify] https://crrev.com/2d0e75a06d24ff78139649b12b245e447f62f518/media/gpu/jpeg_decode_accelerator_unittest.cc