You need to be very very very careful with this. If your rendering thread will ever block waiting for the main thread, then your main thread can NEVER block waiting for the rendering thread.
Like, when it is told the surface is being destroyed, it can't block (like one typically would) to wait for the rendering thread to stop using the surface. You can probably make this work by ensuring that any place the main thread is about to wait for the rendering thread, it sets a flag that it is blocking that prevent the rendering thread from trying to block and ensures the rendering thread wakes up if it is currently blocked. But I suspect that if you go down this road you will be forever dealing with one deadlock after another. On Thu, Jan 6, 2011 at 4:48 PM, Chris <[email protected]> wrote: > Mark, could you give me an example of something that would work? > There's a lot of tools in java.util.concurrent that could probably all > be used to solve this so I could use a push in the right direction. > > Thanks, > Chris > > On Jan 6, 7:24 pm, Mark Murphy <[email protected]> wrote: > > On Thu, Jan 6, 2011 at 7:19 PM, Chris <[email protected]> wrote: > > > Well I'll go one step further and explain the problem. Most of the app > > > is a native C library. > > > > Ahhhhhhhhhhhh. > > > > > The native code runs entirely on the OpenGL > > > thread. Occasionally, the user will perform an operation that requires > > > a function on the UI thread to run. It's imperative that the function > > > runs and returns before the GL thread is allowed to continue because > > > the library needs a piece of hardware to be enabled (which is done on > > > the UI thread). The UI is Thread A in my example and the OpenGL thread > > > is Thread B in my example. > > > > OK. I'll buy that. Personally, I'm more of a fan of > > java.util.concurrent than wait()/notify(), but either should work. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > Android 2.3 Programming Books:http://commonsware.com/books > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
