Well I don't know if Java built a landmine into join() ;-) but in
C/C++ I have used phtread_join() many times (usually as part of an
idiom where you have a thread executing a "while (running) {}" loop
and another thread sets running=false and then join()s the other
thread to make sure it's gone), I've seen my coworkers use it and I
don't remember ever observing, or anybody mentioning anything dubious
about join() -so I'm curious, what's supposed to be the problem?(Not that it matters to my original problem as the rendering thread does not exit as part of onPause() handling...) On Sat, Aug 4, 2012 at 2:49 AM, Indicator Veritatis <[email protected]> wrote: > Of my two favorite books on concurrency in Java, one recommends never using > join() in the first place, the other uses it only for a "poison-pill" in an > implementation of producer-consumer when you know you want to shut it down > if the queue ever empties completely. > > Now I realize it is not very helpful to say "don't do that" without offering > a better alternative, but I see from the other responses that this is not a > simple problem. The best I can do to help is say 1) as above, don't use > 'join()', which is so rarely the right tool 2) don't wait until > onDrawFrame() is called to load libraries. That is much too late in the > process. Even waiting for onResume() might be too late. 3) the suggestion of > using AsyncTask for loading libraries is good, but see Meike's talk about > the 'gotchas' of using AsyncTask. It is at > git://github.com/bmeike/OSCON.git. > > BTW: those two books are "Multithread Programming with Java Technology" by > Berg et al, and "Java Concurrency in Practice" by Goetz. > > > On Thursday, August 2, 2012 8:18:04 AM UTC-7, Latimerius wrote: >> >> I'd like to call join() on it to make sure the thread has exited. >> >> (Broader context for those interested: I have a crash in my GL-based >> app that happens like this: >> >> - device is put to sleep with my app in the foreground >> - an incoming call wakes the device up >> - I receive onResume() and I call onResume() on my GLSurfaceView >> - I receive onPause() almost immediately after onResume() since the >> phone app goes to the background due to the incoming call >> - the time between onResume() and onPause() is rather short but enough >> for GLSurfaceView to go through all of its setup up to and including >> the initial onDrawFrame() call >> - my onDrawFrame() goes into texture & geometry loading routine which >> can take up to several seconds so it's still loading when onPause() is >> called as mentioned previously >> - like many people here I have a globally-accessible method of >> retrieving a reference to my main Activity to be used as the current >> Context. This is used while loading graphics data to read asset >> files. >> - this Context reference however gets nulled out in onPause() in an >> attempt not to leak main Activity instances. As the main thread >> running onPause() nulls it while the rendering thread is still needing >> it to finish loading the program crashes. >> >> The idea is to call GLSurfaceView.onPause() and then wait until the >> rendering thread actually exit. Then null the Context reference.) -- 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
