Martin Desruisseaux wrote: > Jody Garnett a écrit : >> So you understand how Executor is isolating the implementor of >> Callable from external influence; in order to have more flexibility >> and control over what is going on. The trade off and motivations for >> their strict design decisions are clear to you ... do you actually >> agree with them? > I must have missed something... Or I did; lets study the design together. > Executor can not assumes such isolation since Callable was given by > the user. I would be surprised if Sun expressed such a motivation in > their design, but maybe I just missed it. I am working with the assumption that the user sets up the Callable and hands it over to the Executor; from that point on the Executor is calling the shots; any further communication *must* be done using the callback object (a Future in the case) provided by the Executor. This restriction is there so that the Executor can take responsibility for all the threading concerns, communicating the result back to user code (via Future.get) and so on ...
The design is an elegant separation of concerns that benifits both parties: - people writing Callables never have to think about synchronization or any of the hard stuff that usually complicates matters) - people writing Executors have limited exposure to client code on two fronts, both of which they control (and thus can take responsibility for the multi-threading issues). They have the method that accepts a Callable, and they have the Future they give back to client code. They have a few extras like the ability of a client to poll() the Executor for the next Future to complete as well but that is not near as dangerous. This design agrees with the goals of the concurrency model (make thread safe code easier for mortals to write) and so on ... It also gives Executor writers the freedom to take a few radical approaches to getting the results calculated; nothing in this API says the Callable is even valid after it has been handed over to the Executor; indeed the Executor may serialize it out to another machine in a cluster; the Future only provides a way to get the result of the execution (perhaps the result has been stored in a database row by the other machine in the grid? that makes sense with the polling idea above ... hrmmm smart cookies the Executor designers). >> Can I ask if in your experience you are holding on to your Callables >> after passing them to an Executor? > I do not hold Callables, but even if I did I don't see any harm I > could do. Right; where as I would see you holding on to the Callable to be a violation of your responsibility as a client; if you do that (and start poking at the methods) you have set up a line of communication *to the running process* that does not go through the Executor - this is a big mistake and would really compromise the safety of any Executor. Don't even get me started on the "safety" of broadcasting events out of a a listener list; if anything needs to be under the control of an Executor it is that. If you want to see how the Executor / Callable design handles the problem review how the value from a Callable is communicated via a Future back to client code; and the various ways the Executor API provide for client code to check up. As an example the Eclipse Jobs api uses a different flag to stop a Process; (a shared flag that is passed in if you must know). That way it can reuse the Thread to process several Jobs as they are made available out of a Queue. If you are poking away at Jobs in the queue without going in via a Executor provided API then you may screw up the planning routines and make them unfair. If you have another way of cancelling other than the one provided by the Executor it may never be able to report back what happened to the job (and why) to any monitoring screens etc... > If holding Callable is considered harmful, I must have missed something? Please read the above email/rant ... I really like the separation of concerns that Executor provides. I have been drawing pictures of what is going on with several process engines for a couple of weeks and this Executor / Callable / Future relationship is one of the nicer ones. Really I would like you to understand the above design; and then be able to talk to me about tracking progress, the tradeoffs between listeners vs polling in the design of Executor. We also have the WPS specification to draw on (they also do polling but that makes sense for a Internet service). Jody ------------------------------------------------------------------------- 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
