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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
