Hey, Thanks for your valuable insights.
On Wednesday, May 30, 2012 4:15:06 PM UTC+2, G. Blake Meike wrote: > > Well, the error message is for sharedWorkerThread and the code is > sharedPrioThread and I admit I've never actually done exactly this, however > I strongly suspect that this is the Android-ended-your-process issue. > > When Android sees more than a certain number of processes running in > background (14 on my ICS Galaxy) it starts killing them off. They are > restarted in new processes as needed. The new process will need its state > re-initialized. > I wasn't aware of that and yes, the process count sometimes goes up to that number (a lot of Binder and AsynTask threads show up then). As I presume the thread is not re-created by the system as a handler thread when it was killed by it before (does somebody have more information on this?) and thus the looper is not initialized, this might explain the issue. > > ...note, btw, that calls to quit() don't have anything to do with the > value of the field (I presume) sharedPrioThread. > Sorry, I am experimenting with 4 shared threads, each with the same setup but different priorities; seems like I have a mismatch in the code I posted here (so its the source of on of the other 3 threads). Just imaging "sharedPrio" being "sharedWorker" and it should be consistent. The rationale of using 4 threads is that i wanted to find the right priorities for the different tasks I am doing. Some of them lagged substantially behind the others and I tried to speed them up using a higher priority. Finally it turned out that the bottleneck is most probably DB-Inserts (so an IO bottleneck). One thing I noticed when watching CPU load and frequency (with the SystemPanel Lite App) is that is that Android seems to adjust the frequency based on the amount of "urgent" things to do (i.e. threads with a higher priority). So this could lead to the situation that some background stuff (i.e. low prio threads) are not getting CPU time although there is work for them. It seems to me Android just does not want to increase the clock frequency to save engery. Is this basically correct and is there some more backgroud information on the scheduler somewhere? > > Why are you lazily initializing the field? I have to say that, one of the > best things that is coming from the Java communities' interactions with > Android is that they may, finally, quite lazily initializing everything. > It makes programs more complex and it is only rarely useful. > Hope I got your point here. Yes, I am from a Java background (Web/ORM) and just a bit "used to lazy initialization", and thought it does not hurt to maintain this practice especially in resource constrainted environments. > > if sharedPrioThread were static final initialized at creation, I don't > think you'd have the problem. > Will try this and report back if I see the problem again. > > G. Blake Meike > Marakana > > The second edition of Programming Android is now on-line: > http://shop.oreilly.com/product/0636920023005.do > Thanks again! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
