Envisage services often require some form of cleanup. For example, if a plugin offers a service that provides a pool of worker threads, those worker threads should typically be shut down before process exit.
Currently there don't seem to be clean patterns for doing this, and there are some pitfalls with current common approaches. One common pattern has the service object - e.g., the ThreadPoolExecutor for the above example - as a trait on the plugin that offers the service, and then uses the plugin's stop method to shut down the executor. But if using Traits defaults, it's easy to write this in such a way that the executor is accidentally started (and then stopped) during the stop method. That's merely inefficient, but for more complicated things, trying to start a service during application shutdown may not work at all.
There may be ways that Envisage can be improved here. Failing that, we can at least document possible approaches and their pitfalls.
Envisage services often require some form of cleanup. For example, if a plugin offers a service that provides a pool of worker threads, those worker threads should typically be shut down before process exit.
Currently there don't seem to be clean patterns for doing this, and there are some pitfalls with current common approaches. One common pattern has the service object - e.g., the
ThreadPoolExecutorfor the above example - as a trait on the plugin that offers the service, and then uses the plugin'sstopmethod to shut down the executor. But if using Traits defaults, it's easy to write this in such a way that the executor is accidentally started (and then stopped) during thestopmethod. That's merely inefficient, but for more complicated things, trying to start a service during application shutdown may not work at all.There may be ways that Envisage can be improved here. Failing that, we can at least document possible approaches and their pitfalls.