Hello,
I have a service which launches a worker thread. This one launches
another thread (a queue) used to send data
though the network (so the sending of one file can be slow because I
have to wait for the server's response).
In the service's onDestroy() method, I have to wait for the end of the
worker thread, which has to wait for the queue thread. I am currently
using join(), but I read it is not a good solution and indeed I
experienced that ("force close" message).
My queue thread knows when to finish its job thanks to a
BlockingQueue: the queue receives messages which can be the name of a
file to send or a shutdown "signal". The problem is that the
onDestroy() method can be called right after the queue pops a new file
name, so it starts to send it through the network. This operation can
take about 10 seconds if the network is not very responsive. I know I
could set a smaller timeout, but I would like to know the server's
response, in order to keep the application in a correct state.
I have thought about sending a shutdown signal to the queue without
waiting for it (no join()), but if the service is garbage-collected my
thread will be an orphan, so it is also elligible for GC.
I have had another idea: in the service's onDestroy() method, I could
schedule a task (executed only one time), which holds a reference to
the worker thread, sends the shutdown message to the queue and join()s
it. Because the thread used by the task would be managed by the
system, it would not be elligible for GC, so as the worker and queue
threads.
However, this last solution seems to be dirty. What do you think about
it, and have you another solution to this problem ?
Thanks
NB: I have found this thread which discusses about this problem, but I
cannot reply to it:
http://groups.google.com/group/android-developers/browse_thread/thread/47a310494882eb5a/776eef8519d1a4da?#776eef8519d1a4da
I quote an intersting message from this discussion. I use the
BlockingQueue Mark Murphy proposed, in my queue thread (the one to
stop as fast as possible).
On 31 jan 2009, 00:29, Mark Murphy <mmur...@commonsware.com> wrote:
> I try to use queues for controlling work done in background threads,
> mostly because that's how I was controlling background threads in
> pre-Android development. LinkedBlockingQueue is a great choice, though
> there are plenty of others in java.util.concurrent.
>
> (java.util.concurrent, by the way, written by Doug Lea, author of the
> book and the extract of same that M. Perrot linked to)
>
> So, in onDestroy(), I just pop my own KillEvent object on the queue(s)
> and, once the queues get to that message, they terminate their own
> threads simply by falling out of the queue-processing loop. So long as
> your queues don't get backed up too deep, you should be OK, and I think
> there's a priority queue implementation in java.util.concurrent as well
> if your threads still aren't closing up shop fast enough.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
