On 14/09/12 18:21, Michael Meeks wrote:
Hi there,
I just got a crash in the PresentationActivity timerUpdateThread - it's
not related to this (I think) - but I guess this could cause some
nasties I suppose. It seems we're talking to the GUI from multiple
threads concurrently:
As far as I can tell I'm on the main thread when updating the GUI -- my
"UpdateThread" should actually be a runnable (I've now renamed it as
such) -- it is never started manually, but is passed to a handler which
runs the run method on the event/GUI Thread after the specified delay.
So I don't think it's a threading issue causing the crash.
http://developer.android.com/guide/components/processes-and-threads.html
"Additionally, the Andoid UI toolkit is not thread-safe. So, you must
not manipulate your UI from a worker thread—you must do all manipulation
to your user interface from the UI thread. Thus, there are simply two
rules to Android's single thread model:
1. Do not block the UI thread
2. Do not access the Android UI toolkit from outside the UI thread"
I was also amused to stumble over this:
http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
Which is quite amusing ;-) Anyhow - perhaps I'm missing something - I
don't know what mTimeLabel.setText really does so ...
Are we doing our slower IPC in a thread and leaving the main thread to
render ? (things are responsive so I assume so generally :-).
All the networking code is run in a separate thread (as required by
android docs -- networking on the GUI thread results in errors being
thrown -- except for writing to a stream). As far as I can tell all the
GUI work is done in the GUI thread, with the timer update and any
broadcasts from the background threads simply being handled as events on
the GUI thread.
A summary of threads (to the best of my knowledge):
- GUI/event thread -- run by android, handles the timerUpdate events,
and Broadcasts from the networking threads.
- Network handling thread: deals with connecting to a server (i.e. the
opening of a socket, up until sending a pin) and spawning the Client
thread as necessary.
- Client thread: listens to the network/bluetooth socket, and sends out
broadcasts to the UI as appropriate when appropriate data is received on
the socket.
I.e. as far as I can tell all UI work is done on the correct thread.
What is however more complicated is the lifecycle of the activity and
service, which has caused some issues (which is why that
mCommunicationService==null check was needed), etc.
Cheers,
Andrzej
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
