On 02/04/2008, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Hi Sahoo, > > Am Mittwoch, den 02.04.2008, 10:40 +0530 schrieb Sahoo: > > > My observation is that the EventDispatcher thread is the only thread > > that can be configured (well almost configured) as daemon or non-daemon. > > All other threads spawned by Felix are daemon threads. The reason I say > > the event dispatcher thread can be configured is because it inherits the > > daemon status of the parent thread, i.e., the thread that starts Felix. > > So, if I start Felix on a daemon thread then that becomes a daemon > > thread. I don't think this is documented any where, is this? Can I rely > > on this behavior? If not, can we add a configuration option for this? > > Just a quick question for validation: Why do you care ?
FYI, one reason to care is that the JVM will exit if only daemon threads remain - so it's important for people to know that when you create a new thread it inherits the daemon status of the thread creating it. I don't believe it is spec'd what sort of threads OSGi frameworks should use, so OSGi users should be careful when creating new threads inside their bundle activators. the safest approach is to always set the daemon status of a new thread, that way you know whether it's a daemon or not regardless of what sort of threads a framework uses... The threads are all internal implementation details and managed through > the lifecycle methods of OSGi (generally BundelActivator start/stop). If > a thread happens to still run after the framework has been stopped, this > should be considered an error of the respective bundle and should be > fixed. > > Having said this, I nevertheless generally define my threads (I did the > ones in the scr and configadmin bundles) as daemon threads. > > Regards > > Felix > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
