Android optimization for Attach/Detach from C callbacks

[tmm1]

fixes #242

[tmm1]

I tested this on my Android device and it works as expected.

[saudet]

Looks good, thanks!! Although I'm not sure I see why the lock is needed... Anyway, let's prefix the static variables to avoid name clashes with libraries the user might be trying to wrap, something like JavaCPP_current_env, JavaCPP_once, and JavaCPP_lock?

[tmm1]

I think the lock is needed around the getspecific/setspecific.

Renaming the statics makes sense, I can do that.

[saudet]

That's what I'm thinking, or maybe the once guy? It doesn't make sense that either of those would not be thread-safe though, and it's not in the docs, but anyway if that's what's needed according to FFmpeg developers, let's just do that.

Yes, please change the names, thanks!

[tmm1]

The pthread_once likely does not need to be inside the lock, though it was in the ffmpeg code I copied from.

The lock is needed around the get/set only, since that's two separate operations that could race.

[saudet]

This is a thread-specific variable, there can't be any race conditions. There must be some other reason though.

[tmm1]

Yes, please change the names, thanks!

Done.

[tmm1]

cc @mbouron in case he remembers the reason for the lock

[egolearner]

I think pthread mutex in ffmpeg is used to protect java_vm global variable.

https://github.com/FFmpeg/FFmpeg/blob/575e52272d42f4278c6620f1a999c41425db2094/libavcodec/ffjni.c#L51-L72

In javacpp, JavaCPP_vm is set elsewhere so it's unnecessary to use pthread mutex.