NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: