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 bef
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 wrote:
> On Thu, Jan 6, 2011 at 7:19 PM, Chris
It may be that you need to change how you think of your code.
All mobile platforms (and a good many other platforms as well) use an
even model. They don't wait on another thread really, they wait for an
event to happen.
What your talking about would be dangerous on any platform, but on a
mobile p
Assuming there may actually be data to be transferred (or you invent
some), you can use an ArrayBlockingQueue.
Otherwise, wait()/notify() is a good choice, but you need to be
careful to handle the case that the UI thread does the notify before
you get into the wait() code. The usage pattern should
Probably you just need some flag signaling that your hardware isn't
ready. Rendering thread always runs without blocking, checks for this
flag and do not do certain things (may be render function just returns
right away). UI thread sets the flag and then rendering thread checks
for it.
On 9 янв, 1
Yes. The assumption here is that you are not interrupting it yourself
(there's no need here), and someone else interrupting it would be bad.
You could log it, but it's a rather remote possibility.
If, on the other hand, you're making a library, you might want to take
a different option at that poi
On Thu, Jan 6, 2011 at 7:19 PM, Chris wrote:
> Well I'll go one step further and explain the problem. Most of the app
> is a native C library.
A.
> The native code runs entirely on the OpenGL
> thread. Occasionally, the user will perform an operation that requires
> a function on the
On Thu, Jan 6, 2011 at 6:24 PM, Mark Murphy wrote:
> OK. I'll buy that. Personally, I'm more of a fan of java.util.concurrent
> than wait()/notify(), but either should work.
>
I'd listen to Mark - I just pointed to the first thing that came to mind as
a starting point.
-
On Thu, Jan 6, 2011 at 7:48 PM, Chris 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.
Actually, upon further review, for your ca
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 fo
08.01.2011 10:37, Bob Kerns пишет:
Memorize this pattern! If you're using notify/wait, it should ALWAYS
look something like this.
Always - except unless you actually want to respect the meaning of
InterruptedException and unwind the code around wait() to the caller,
canceling the operation.
11 matches
Mail list logo