Should ~GLES2Implementation run WaitForCmd during browser shut down?

I was restarting a Chrome with a lot of windows and tabs open on Mac and noticed it took quite a while to shut down. I took a sample via Activity Monitor and symbolized it.

It looks like the browser thread was spending a lot of time in destructing GpuProcessTransportFactory() and its owned objects, here's what's happening on the main thread during the 3s sample:

Call graph:
    2466 Thread_43716270   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2466 start  (in Google Chrome)  load address 0x10eb25000 + 0xb24  []
    +   2466 main  (in Google Chrome) + 530  [chrome_exe_main_mac.c:89]
    +     2466 ChromeMain  (in Google Chrome Framework) + 66  [chrome_main.cc:66]
    +       2466 content::ContentMain(content::ContentMainParams const&)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x53bf06  [content_main.cc:19]
    +         2466 content::ContentMainRunnerImpl::Run()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x53c99c  [content_main_runner.cc:808]
    +           2466 content::BrowserMain(content::MainFunctionParams const&)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x34a5e19  [scoped_ptr.h:128]
    +             2466 content::BrowserMainRunnerImpl::Shutdown()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x34acd4d  [browser_main_runner.cc:293]
    +               2466 content::BrowserMainLoop::ShutdownThreadsAndCleanUp()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x34aa8a4  [trace_event.h:803]
    +                 2466 content::ImageTransportFactory::Terminate()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x37a6848  [image_transport_factory.cc:51]
    +                   2466 non-virtual thunk to content::GpuProcessTransportFactory::~GpuProcessTransportFactory()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x37a3425  [gpu_process_transport_factory.cc:123]
    +                     2466 content::GpuProcessTransportFactory::~GpuProcessTransportFactory()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x37a32da  [scoped_ptr.h:241]
    +                       2466 content::ContextProviderCommandBuffer::~ContextProviderCommandBuffer()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfdde9e  [context_provider_command_buffer.cc:59]
    +                         2466 content::ContextProviderCommandBuffer::~ContextProviderCommandBuffer()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfdde6d  [ref_counted.h:189]
    +                           2466 content::GrGLInterfaceForWebGraphicsContext3D::~GrGLInterfaceForWebGraphicsContext3D()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfed22e  [grcontext_for_webgraphicscontext3d.cc:95]
    +                             2466 content::GrGLInterfaceForWebGraphicsContext3D::~GrGLInterfaceForWebGraphicsContext3D()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfed195  [GrGLInterface.h:106]
    +                               2466 content::WebGraphicsContext3DCommandBufferImpl::~WebGraphicsContext3DCommandBufferImpl()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfedade  [webgraphicscontext3d_command_buffer_impl.cc:119]
    +                                 2466 content::WebGraphicsContext3DCommandBufferImpl::~WebGraphicsContext3DCommandBufferImpl()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfed883  [weak_ptr.h:272]
    +                                   2466 content::WebGraphicsContext3DCommandBufferImpl::Destroy()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfeda0d  [scoped_ptr.h:241]
    +                                     2466 <name omitted>  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x16cc3ee  [gles2_implementation.cc:234]
    +                                       2466 gpu::gles2::GLES2Implementation::~GLES2Implementation()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x16cbcf6  [scoped_ptr.h:241]
    +                                         2466 gpu::gles2::GLES2Implementation::WaitForCmd()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x16cc122  [trace_event.h:803]
    +                                           2466 gpu::CommandBufferHelper::Finish()  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x1168beb  [cmd_buffer_helper.cc:165]
    +                                             2466 content::CommandBufferProxyImpl::WaitForGetOffsetInRange(int, int)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfdb00d  [command_buffer_proxy_impl.cc:693]
    +                                               2466 content::GpuChannelHost::Send(IPC::Message*)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0xfe69b7  [gpu_channel_host.cc:124]
    +                                                 2466 IPC::SyncChannel::Send(IPC::Message*)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x1043861  [ipc_sync_channel.cc:502]
    +                                                   2466 IPC::SyncChannel::WaitForReply(IPC::SyncChannel::SyncContext*, base::WaitableEvent*)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x1043ac3  [ipc_sync_channel.cc:517]
    +                                                     2466 base::WaitableEvent::WaitMany(base::WaitableEvent**, unsigned long)  (in Google Chrome Framework)  load address 0x10ed8c000 + 0x5d09b8  [waitable_event_posix.cc:126]
    +                                                       2466 _pthread_cond_wait  (in libsystem_pthread.dylib) + 767  [0x7fff9678073d]
    +                                                         2466 __psynch_cvwait  (in libsystem_kernel.dylib) + 10  [0x7fff93025f5e]


To me, it seems like maybe the work being done in WaitForCmd() is not necessary during browser shut down - since everything is going away? Perhaps there can be a special case there to just exit with doing very minimal work in that case - since it doesn't seem to me that making the user wait many seconds for this makes sense if the browser is shutting down. WDYT? Over to piman@ who I think works on command buffers for triage.