Felix Meschberger wrote:
+ PackageAdmin - One thread per framework (Felix) instance
This was the main other culprit I was thinking about and clearly it
doesn't have enough activity to keep itself busy, so it might be a good
candidate for sharing if possible to do it cleanly.
+ EventDispatcher - One thread per class loader hierarchy, shared by
potentially multiple framework instances
+ StartLevel - One thread per framework instances
This one should be investigated too.
+ SystemBundle - One thread created to asynchronously stop the
framework
This one is not an issue since the thread just lives transiently to stop
the framework instance.
+ Config Admin - One thread per framework instance (to dispatch
configuration)
+ Declarative Services - One thread per framework instance (to
enable/disable components)
+ EventAdmin - Thread Pool of configurable size per framework instance
I am not so concerned about bundles, but it is also possible for us to
consider some sort of thread pool service for them.
I wonder, whether it would be worth it to have a general "task
dispatching"
facility, which would manage the threads. Or have the threads to be
separate
such that for example asynchronous EventDispatcher events are not
postponed
until an eventual StartLevel change has finished ?
Yeah, I don't think we want to go too crazy. I think it makes sense to
try to aggregate threads a little, but we don't want to over do it.
This is just a quick idea off the top of my head and I only have a very
vague idea of how to implement it...
For me, the important ones are the ones used by the framework. For the
framework, we could consider some sort of Thread Pool/Task manager...it
seems like a do-able task. However, the secondary goal for the framework
is to stay simple, so I would only be in favor of it if it didn't add
any bloat. Could be interesting to investigate though.
-> richard
