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.
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 янв,
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
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
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
On Thu, Jan 6, 2011 at 7:19 PM, Chris cjse...@gmail.com 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
On Thu, Jan 6, 2011 at 6:24 PM, Mark Murphy mmur...@commonsware.com 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.
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 mmur...@commonsware.com wrote:
On Thu, Jan 6,
On Thu, Jan 6, 2011 at 7:48 PM, Chris cjse...@gmail.com 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
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
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
11 matches
Mail list logo
