Now that we are getting more controllers on the bus, Eyal Katz pointed out that we are still using the old mechanism of propagating messages from the ReflectionBus to objects which needn't run on the Swing thread using the Swing thread. While this is not dangerous, it will cause the application to slow down eventually.
Tonight I put a mechanism in the BusSignal to change that. If you don't specify anything, the signal will automatically get propagated on the Swing thread. However, for signals going out from the Swing thread, onto the bus, and to a controller, you should use the method supplied in the BusSignal class to switch the SignalConnector used.
super.
setSignalConnector(GENERIC_CONNECTOR);
This generic connector simply invokes the method directly and does not wrap it in a runnable for the Swing thread. That means the controllers will currently run on the bus thread and not the Swing thread. That's as they ought to be.
In the near future, as the controllers get a bit more finalized, I'll create threaded wrapper classes that can be put around the controllers if an application needs to run that controller on a separate thread. So the command class to create that controller would take a constant on the constructor indicating if it should instantiate the controller with its own thread or not. If so, the instantiation would look like this:
new ThreadedPrintController(new PrintController);
Inside the threaded print controller would be a spin lock that would accept messages and put them in a queue. It would then exctract them from the queue and invoke the proper method. This involves another step in the process so must be weighed carefully against the benefits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that we are getting more controllers on the bus, Eyal Katz pointed out that we are still using the old mechanism of propagating messages from the ReflectionBus to objects which needn't run on the Swing thread using the Swing thread. While this is not dangerous, it will cause the application to slow down eventually.
Tonight I put a mechanism in the BusSignal to change that. If you don't specify anything, the signal will automatically get propagated on the Swing thread. However, for signals going out from the Swing thread, onto the bus, and to a controller, you should use the method supplied in the BusSignal class to switch the SignalConnector used.
super.
setSignalConnector(GENERIC_CONNECTOR);
This generic connector simply invokes the method directly and does not wrap it in a runnable for the Swing thread. That means the controllers will currently run on the bus thread and not the Swing thread. That's as they ought to be.
In the near future, as the controllers get a bit more finalized, I'll create threaded wrapper classes that can be put around the controllers if an application needs to run that controller on a separate thread. So the command class to create that controller would take a constant on the constructor indicating if it should instantiate the controller with its own thread or not. If so, the instantiation would look like this:
new ThreadedPrintController(new PrintController);
Inside the threaded print controller would be a spin lock that would accept messages and put them in a queue. It would then exctract them from the queue and invoke the proper method. This involves another step in the process so must be weighed carefully against the benefits.