Jody Garnett a écrit : > Thread and Runnable are a good base, but the design suffers from some > serious flaws with respect to canceling a running Thread.
Runnable or Callable can be extended with a cancel() method. This is what I'm pushing for. I have the feeling that our disagreement come from the fact that the following recommandation doesn't seem an option in your proposal: http://java.sun.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html Please scroll down to "What should I use instead of Thread.stop?" > There is one point of contact, the code that starts the thread needs to > end it etc... But we don't need a point of contact! We would need a point of contact if a call to Thread.interrupt() was the only way to stop a process, i.e. if the process has no build-in support for cancelation. But if you require a process to implement the Process interface and if this interface requires to implement a cancel() method, then implementors are required to support cancelation in the way recommanded by the link above (or something similar). This is what Image I/O does and it work well (I use it). The Future.cancel() method could be seen as more aggresive way to cancel a progress for the waiting thread only. This is not the only way and not necessarly the preferred one since the approach in the above link would leave the system in a cleaner state. > These facilities do not provide any kind of information or reporting on > the running Callable. The moment we provide more we have stepped outside > of what Future / Callable can do out of the box. Yes but again why the following is not acceptable? interface Process extends Callable { void addProgressListener(...) void removeProgressListener(...) void cancel(); } > To answer your question - it is not compatible with the > relationship/responsibilities between and Future/Callable. While it is a > fine approach; it goes against the design of the system. It goes against the usage of Future.cancel(), but I don't see that as a problem. * Listeners can stop a process using Process.cancel(), which should be implemented in the way described in the above link as in Image I/O. * The thread that holds the Future object can invokes Process.cancel() or Future.cancel() at its choice - the later can been see as a more aggressive way to kill a process if we don't want to let it finish cleanly. To compare with unix commands: "Process.cancel()" is like "kill PID" : kill cleanly. "Future.cancel(true)" is like "kill -9 PID" : kill immediately. > So my turn to ask ... what is the problem? If a standard API exists (ISO, OGC or JCP), I would like to push very hard for using it. Creating our own API on our side add conceptual complexity: developpers need to keep in their brain a wider range of relationships. So why Process needs to be unrelated to Callable? The need for reporting progress and supporting cancelation doesn't prevent us from defining Process as a Callable specialisation as far as I can see. Yet better, it gives us a way to stop a process cleanly, as an alternative to the aggressive Thread.interrupt() which could be used in last ressort. Martin ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
