Curtis Rueden wrote:
Hi Stuart,
Thanks for pointing this out. I'll take a look at it in more detail
later this week, but initially I do have one comment. Rather than
using interrupts, a slightly cleaner way would be to use monitors with
wait and notifyAll, like the code is already doing. It might take
slightly longer than interrupt in certain cases (I'm not sure), but it
gives you more control over the flow of the code. For example, the
graphics context will always get properly disposed.
Hi Curtis, good point. I think I chose interrupts since they are not 'lost' like notifies can be. Thread.interrupt sets the
interrupt status on a Thread, a definite change in program state. Calls like Object.wait check this status (and reset it!), and
throw InterruptedException (IE) before/during the wait. I found the problem with just wait/notify is that using notify to halt
a thread relies on the wait having happened earlier, if not, you are stuck. So its a race condition. The interrupt approach is
actually similar to the CountdownLatch set to one, used as an 'event'.
But I do see your point re other objects in a bad state in the app. But is it not the responsibility of say a Graphics object
user to catch any IE, dispose of objects correctly and maybe re-throw the IE.
Your comments welcomed
Stuart
