Stuart McCulloch wrote:
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...
I am not starting any thread inside my bundle. The thread in question is
an Felix specific thread. It right now inherits the status of the thread
that starts Felix. There are three options:
1) We document this behavior so that people can rely on it.
2) Always set daemon status = true
3) Use a property to configure the status.
#3 is the best alternative IMO and it's pretty easy to implement.
Now coming to the point of why users care, as Stuart rightly pointed
out, users who embed Felix in their application don't want the
application to hang around even after all the application threads are
gone. Today to ensure that, they have to rely on an undocumented feature
(i.e. option #1).
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
