diff options
| author | Tor Lillqvist <tml@collabora.com> | 2014-10-15 12:02:44 +0300 |
|---|---|---|
| committer | Tor Lillqvist <tml@collabora.com> | 2014-10-15 15:42:00 +0300 |
| commit | c809b37e55221dbe445d1705b057f76b6527e92e (patch) | |
| tree | c9727c173650180dac2aeb2411a9ea09354f8420 | |
| parent | Skip the 'desktop' app for now (diff) | |
| download | core-c809b37e55221dbe445d1705b057f76b6527e92e.tar.gz core-c809b37e55221dbe445d1705b057f76b6527e92e.zip | |
Call DetachCurrentThread() in the AndroidSalInstance destructor
As we call AttachCurrentThread() in the constructor, it seems logical to call
DetachCurrentThread() in the destructor. Some warning messages in the logcat
indicated that DetachCurrentThread() hadn't been called for a thread that
died.
Actually I would prefer to call both AttachCurrentThread() and
DetachCurrentThread() in the actual thread function, instead of somewhat
haphazardly and imlicitly in the AndroidSalInstance constructor and
destructor. Do we know for sure that the lifetime of the AndroidSalInstance
singleton (is is a singleton, right?) is 1:1 coupled to that of the LO "main
thread"?
Change-Id: Ifcc0e0b9af88b19389c416c5646499d44ad0e941
| -rw-r--r-- | vcl/android/androidinst.cxx | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/vcl/android/androidinst.cxx b/vcl/android/androidinst.cxx index 262a7c1ea3c2..8059d336fa28 100644 --- a/vcl/android/androidinst.cxx +++ b/vcl/android/androidinst.cxx @@ -192,6 +192,8 @@ AndroidSalInstance::AndroidSalInstance( SalYieldMutex *pMutex ) AndroidSalInstance::~AndroidSalInstance() { + int res = (lo_get_javavm())->DetachCurrentThread(); + LOGI("DetachCurrentThread res=%d", res); LOGI("destroyed Android Sal Instance"); } |