[Ozone-Drm] Fallback silently when main thread runner is not present

[Ozone-Drm] Fallback silently when main thread runner is not present

BUG=471261
TEST=GBM platform on gpu_unittests and content_unittests

[vignatti (out of this project), 2015-03-30 20:47:41]

tiago.vignatti@intel.com changed reviewers:
+ dnicoara@chromium.org, spang@chromium.org

[vignatti (out of this project), 2015-03-30 20:47:49]

PTAL.

[vignatti (out of this project), 2015-04-06 23:55:53]

spang@ PTAL here. 

I'm starting to think that the most practical way to fix the unit tests (and
avoid CL 1043233003 entirely) is doing like this... after all, the main thread
runner, which is the source of all the trouble, is a temporary solution for the
cursor stuff and hopefully that won't be needed eventually.

[spang, 2015-04-07 19:04:31]

On 2015/04/06 23:55:53, vignatti wrote:
> spang@ PTAL here. 
> 
> I'm starting to think that the most practical way to fix the unit tests (and
> avoid CL 1043233003 entirely) is doing like this... after all, the main thread
> runner, which is the source of all the trouble, is a temporary solution for
the
> cursor stuff and hopefully that won't be needed eventually.

Is it worth having a hack for this?

We don't run these unit tests with gbm on the waterfall (and realistically,
probably cannot do so). I'm not sure if it is actually even worthwhile to try,
because they are unit tests for other components and should not depend on
particular behavior at the platform layer.

If you could elaborate as to why you need it to work, that would help justify
why we need to check in a hack to support it.

[vignatti (out of this project), 2015-04-08 21:59:33]

On 2015/04/07 19:04:31, spang wrote:
> On 2015/04/06 23:55:53, vignatti wrote:
> > spang@ PTAL here. 
> > 
> > I'm starting to think that the most practical way to fix the unit tests (and
> > avoid CL 1043233003 entirely) is doing like this... after all, the main
thread
> > runner, which is the source of all the trouble, is a temporary solution for
> the
> > cursor stuff and hopefully that won't be needed eventually.
> 
> Is it worth having a hack for this?
> 
> We don't run these unit tests with gbm on the waterfall (and realistically,
> probably cannot do so). I'm not sure if it is actually even worthwhile to try,
> because they are unit tests for other components and should not depend on
> particular behavior at the platform layer.
> 
> If you could elaborate as to why you need it to work, that would help justify
> why we need to check in a hack to support it.

noupe, we agreed that it's not worth this:
https://code.google.com/p/chromium/issues/detail?id=471261#c3

closing this CL as well.