Well I'll go one step further and explain the problem. Most of the app is a native C library. 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.
On Jan 6, 7:07 pm, Mark Murphy <mmur...@commonsware.com> wrote: > On Thu, Jan 6, 2011 at 6:53 PM, Chris <cjse...@gmail.com> wrote: > > This is probably a "newbish" question but let's say i'm in Thread B > > and I need to do something on my UI Thread (Thread A) but it's > > critical that B doesn't continue to execute until A has gotten around > > to actually handling my request. > > Pro tip: don't do this. > > > ...but i want to wait for that call to actually go through. What are > > some ways of doing this? > > There are plenty of Java synchronization options (the wait()/notify() > that TreKing pointed out, plus all the stuff in java.util.concurrent). > > That being said, I am dubious that this is a good idea in the first place. > > -- > 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 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
