Excellent analysis here, Berin!
> interface Interruptable extends Executable {
+1
> Regarding the case where something is "startable" with no direct
> control over
> when it stops, I want to promote the "Command" pattern.
+1. Agreeing one hundred percent here - this is the best solution
I know for long-running threads.
> Basically, we would have an interface for the Command object like this:
>
> interface Command {
> void execute();
> }
>
> We would either provide a CommandQueue, or have that command object start
> after the Component it affects is fully set up.
I'm for the latter...It makes sense to have the managing object worry about
how to start the commands. So
// ...
myComponent.init();
myComponent.start(); // or should this go after getCommands()?
Iterator commands = ((Commandable)myComponent).getCommands();
for(commands.hasNext()) {
myThreadPool.add(new WorkerThread(commands.next()));
}
myComponent.run();
myThreadPool.runAll();
myComponent.interrupt(); // component is responsible for interrupting
// Commands if that is neccessary
myComponent.resume(); // component is responsible for resuming interrupted
// commands
myComponent.stop();
// ... shutdown
myThreadPool.stopAll(); // guaranteed before dispose()
myThreadPool.disposeAll(); // guaranteed before dispose()
myComponent.dispose();
myComponent = null;
myThreadPool = null; // last reference gone
System.gc();
// ...
is possible. In the above (which will work with Phases in practice),
Command would have to look like this:
interface Command extends Runnable { // or we could extend Thread,
// which means even more
options
// but also a more heavyweight
// solution.
void run() throws CascadingRuntimeException;
}
which would allow re-use of std pooling systems. It needs to be
guaranteed that getCommands() is called after start() but before
run(), and that the run() of the returned commands is called
right after the run() of the component (I'm not sure this is the
right place for those methods; important is that their point of
execution is clearly defined).
This setup has maximum flexibility while allowing complete
manageability. I'm kinda wondering why the Command pattern was
removed from the code...
cheers,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
