Fix android errors when unflattening an SkImageRef_ashmem object.

Fix android errors when unflattening an SkImageRef_ashmem object.

Committed: https://code.google.com/p/skia/source/detail?r=7514

[Leon, 2013-01-31 15:43:23]

So the new behavior is that SkImageRef_ashmem will share the same mutex with all
SkImageRefs? Might it make sense for SkImageRef_ashmem to have its own global? I
see that we don't want ashmem collisions, but this seems like it goes too far.

Also, if we remove these calls to useDefaultMutex, should we also remove the
function itself since no one else calls it?

[DerekS, 2013-01-31 15:50:14]

So the big problem is that in SkImageRef we have asserts everywhere like this
SkASSERT(&gImageRefMutex == this->mutex());  However, as you can guess if you
put in a different mutex these asserts are invalid.

Perhaps the right thing to do is rewrite SkImageRef to no longer make that
assumption.

[DerekS, 2013-01-31 18:37:16]

should I keep the ashmem header in src or move it to include?

[reed1, 2013-01-31 19:46:05]

generic answer (take with grain of salt:) keep in src until absolutely necessary
to make public

[DerekS, 2013-01-31 19:54:43]

On 2013/01/31 19:46:05, reed1 wrote:
> generic answer (take with grain of salt:) keep in src until absolutely
necessary
> to make public

ok. review?

[Leon, 2013-01-31 20:30:36]

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp
File gyp/images.gyp (right):

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp#newcode25
gyp/images.gyp:25: '../include/images/SkImageRef_ashmem.h',
Isn't the file in src/?

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp#newcode126
gyp/images.gyp:126: '../src/images/SkImageRef_ashmem.cpp',
Should we remove the header as well?

https://codereview.appspot.com/7228071/diff/4001/src/images/SkImageRef.cpp
File src/images/SkImageRef.cpp (left):

https://codereview.appspot.com/7228071/diff/4001/src/images/SkImageRef.cpp#ol...
src/images/SkImageRef.cpp:19: SK_DECLARE_GLOBAL_MUTEX(gImageRefMutex);
This is the only place we call SK_DECLARE_GLOBAL_MUTEX. Should we get rid of it
as well? Or do we think it is potentially valuable?

[DerekS, 2013-02-01 13:59:49]

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp
File gyp/images.gyp (right):

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp#newcode25
gyp/images.gyp:25: '../include/images/SkImageRef_ashmem.h',
On 2013/01/31 20:30:36, scroggo-work wrote:
> Isn't the file in src/?

Done.

https://codereview.appspot.com/7228071/diff/4001/gyp/images.gyp#newcode126
gyp/images.gyp:126: '../src/images/SkImageRef_ashmem.cpp',
On 2013/01/31 20:30:36, scroggo-work wrote:
> Should we remove the header as well?

Done.

https://codereview.appspot.com/7228071/diff/4001/src/images/SkImageRef.cpp
File src/images/SkImageRef.cpp (left):

https://codereview.appspot.com/7228071/diff/4001/src/images/SkImageRef.cpp#ol...
src/images/SkImageRef.cpp:19: SK_DECLARE_GLOBAL_MUTEX(gImageRefMutex);
On 2013/01/31 20:30:36, scroggo-work wrote:
> This is the only place we call SK_DECLARE_GLOBAL_MUTEX. Should we get rid of
it
> as well? Or do we think it is potentially valuable?

I think it is potentially valuable so that if we want to utilize this in the
future.  That way we can point authors of new code to that file and explain why
they should use the macro.

[Leon, 2013-02-01 15:51:55]

https://codereview.appspot.com/7228071/diff/4001/src/images/SkImageRef.cpp#ol...
> src/images/SkImageRef.cpp:19: SK_DECLARE_GLOBAL_MUTEX(gImageRefMutex);
> On 2013/01/31 20:30:36, scroggo-work wrote:
> > This is the only place we call SK_DECLARE_GLOBAL_MUTEX. Should we get rid of
> it
> > as well? Or do we think it is potentially valuable?
> 
> I think it is potentially valuable so that if we want to utilize this in the
> future.  That way we can point authors of new code to that file and explain
why
> they should use the macro.

Sounds reasonable to me. LGTM