You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sahoo <Sa...@Sun.COM> on 2008/04/02 07:10:24 UTC
non-daemon thread in Felix
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?
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Stuart McCulloch <st...@jayway.net>.
On 02/04/2008, Sahoo <sa...@sun.com> wrote:
>
> Stuart McCulloch wrote:
> > On 02/04/2008, Felix Meschberger <fm...@gmail.com> 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.
yes - I know you were talking about Felix's own threads :)
but this was a good time to point out that users should be aware
their threads will inherit the daemon status from the framework
thread, and for most OSGi frameworks this is set to true
there has already been one Equinox user that was caught out
by this, and I think it's important to stress this fact here as well
(I'm also adding it to the FAQ)
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: non-daemon thread in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I am basically in agreement with Karl. I don't think we need to do much
more than document the fact that you can change the daemon status of
Felix by starting it from an appropriately configured thread.
In truth, I almost feel like it is reasonable to say that the event
dispatching thread should always be non-daemon, since the reason why it
is not daemon is to ensure that all events get delivered, where if it is
daemon it may not deliver all events if it is the only thread left.
However, I guess some people may not care about this, so in that case
the current situation allows them to configure it.
We should probably add this to our FAQ and/or any other place that makes
sense...
-> richard
Karl Pauls wrote:
>> Hi Sahoo,
>>
>> Am Mittwoch, den 02.04.2008, 11:43 +0530 schrieb Sahoo:
>>
>>
>>> 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).
>>
>> In a traditional application you are absolutely right, and I would mark
>> all threads there as daemon threads unless they do very specific tasks.
>> For this reason I mark my threads as daemon threads.
>>
>> Now for an OSGi framework the situation is different: as I said, the
>> bundle starting the thread should also stop it. Thus if you stop the
>> framework correctly, which is what I assume, there will be no framework
>> threads be hanging around after the framework terminated. Hence it is of
>> no importance of whether the threads were daemon or non-deamon threads.
>>
>> If you OTOH do not shut down the framework before trying to shutdown
>> your application in which the framework is embedded, well, yes, you are
>> not behaving correctly, if I may say so ;-)
>>
>> Now, I try to imagine a situation, where you do not shutdown the
>> framework and do not call System.exit() but just terminate all
>> non-daemon thread to terminate the application. In this case of course,
>> it is important to know whether any threads are started by the framework
>> - or any bundle at all, because EventAdmin is implemented in a real
>> separate bundle - are daemon or non-daemon. Is this your use scenario ?
>>
>> Actually, this scenario leads me to think that the event admin should
>> define the threads as daemon threads for clarity and not have a
>> configuration option or a documented state. Because the documented
>> behaviour is to just stop the bundle to shutdown ;-)
>>
>
> I think he is talking about the EventDispatcher which is a framework
> internal class not related to the EventAdmin.
>
>
>> Regards
>> Felix
>>
>
> Sahoo, we do want the framework to inherit the status of the thread it
> has been created with. That doesn't prevent any installed bundle from
> running a none daemon threads so -- hence, as Felix points out, the
> correct way to shutdown the framework is to stop the system bundle so
> that all bundles get stopped and get a chance to clean-up their
> threads.
>
> I agree that we should document this some place.
>
> regards,
>
> Karl
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Karl Pauls <ka...@gmail.com>.
> Hi Sahoo,
>
> Am Mittwoch, den 02.04.2008, 11:43 +0530 schrieb Sahoo:
>
> > 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).
>
> In a traditional application you are absolutely right, and I would mark
> all threads there as daemon threads unless they do very specific tasks.
> For this reason I mark my threads as daemon threads.
>
> Now for an OSGi framework the situation is different: as I said, the
> bundle starting the thread should also stop it. Thus if you stop the
> framework correctly, which is what I assume, there will be no framework
> threads be hanging around after the framework terminated. Hence it is of
> no importance of whether the threads were daemon or non-deamon threads.
>
> If you OTOH do not shut down the framework before trying to shutdown
> your application in which the framework is embedded, well, yes, you are
> not behaving correctly, if I may say so ;-)
>
> Now, I try to imagine a situation, where you do not shutdown the
> framework and do not call System.exit() but just terminate all
> non-daemon thread to terminate the application. In this case of course,
> it is important to know whether any threads are started by the framework
> - or any bundle at all, because EventAdmin is implemented in a real
> separate bundle - are daemon or non-daemon. Is this your use scenario ?
>
> Actually, this scenario leads me to think that the event admin should
> define the threads as daemon threads for clarity and not have a
> configuration option or a documented state. Because the documented
> behaviour is to just stop the bundle to shutdown ;-)
I think he is talking about the EventDispatcher which is a framework
internal class not related to the EventAdmin.
> Regards
> Felix
Sahoo, we do want the framework to inherit the status of the thread it
has been created with. That doesn't prevent any installed bundle from
running a none daemon threads so -- hence, as Felix points out, the
correct way to shutdown the framework is to stop the system bundle so
that all bundles get stopped and get a chance to clean-up their
threads.
I agree that we should document this some place.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Sahoo <Sa...@sun.com>.
Felix Meschberger wrote:
> Hi Sahoo,
>
> Am Mittwoch, den 02.04.2008, 11:43 +0530 schrieb Sahoo:
>
>> 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).
>>
>
> In a traditional application you are absolutely right, and I would mark
> all threads there as daemon threads unless they do very specific tasks.
> For this reason I mark my threads as daemon threads.
>
> Now for an OSGi framework the situation is different: as I said, the
> bundle starting the thread should also stop it. Thus if you stop the
> framework correctly, which is what I assume, there will be no framework
> threads be hanging around after the framework terminated. Hence it is of
> no importance of whether the threads were daemon or non-deamon threads.
>
Agreed.
> If you OTOH do not shut down the framework before trying to shutdown
> your application in which the framework is embedded, well, yes, you are
> not behaving correctly, if I may say so ;-)
>
You are right. I am aware of it and have plans to fix it in immediate
future.
> Now, I try to imagine a situation, where you do not shutdown the
> framework and do not call System.exit() but just terminate all
> non-daemon thread to terminate the application. In this case of course,
> it is important to know whether any threads are started by the framework
> - or any bundle at all, because EventAdmin is implemented in a real
> separate bundle - are daemon or non-daemon. Is this your use scenario ?
>
Yes.
> Actually, this scenario leads me to think that the event admin should
> define the threads as daemon threads for clarity and not have a
> configuration option or a documented state. Because the documented
> behaviour is to just stop the bundle to shutdown ;-)
>
There seems to be a general consensus around documenting the current
behavior - which I think is a reasonable decision.
Thanks,
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Sahoo,
Am Mittwoch, den 02.04.2008, 11:43 +0530 schrieb Sahoo:
> 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).
In a traditional application you are absolutely right, and I would mark
all threads there as daemon threads unless they do very specific tasks.
For this reason I mark my threads as daemon threads.
Now for an OSGi framework the situation is different: as I said, the
bundle starting the thread should also stop it. Thus if you stop the
framework correctly, which is what I assume, there will be no framework
threads be hanging around after the framework terminated. Hence it is of
no importance of whether the threads were daemon or non-deamon threads.
If you OTOH do not shut down the framework before trying to shutdown
your application in which the framework is embedded, well, yes, you are
not behaving correctly, if I may say so ;-)
Now, I try to imagine a situation, where you do not shutdown the
framework and do not call System.exit() but just terminate all
non-daemon thread to terminate the application. In this case of course,
it is important to know whether any threads are started by the framework
- or any bundle at all, because EventAdmin is implemented in a real
separate bundle - are daemon or non-daemon. Is this your use scenario ?
Actually, this scenario leads me to think that the event admin should
define the threads as daemon threads for clarity and not have a
configuration option or a documented state. Because the documented
behaviour is to just stop the bundle to shutdown ;-)
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Sahoo <sa...@sun.com>.
Stuart McCulloch wrote:
> On 02/04/2008, Felix Meschberger <fm...@gmail.com> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: non-daemon thread in Felix
Posted by Stuart McCulloch <st...@jayway.net>.
On 02/04/2008, Felix Meschberger <fm...@gmail.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: non-daemon thread in Felix
Posted by Felix Meschberger <fm...@gmail.com>.
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 ?
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org