Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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
visad archives: