Nektarios K. Papadopoulos wrote:
Alex Karasulu wrote:
Personally I don't understand why there is another thread? What's
the point to it? Can't you just detect that stdin is not valid and
just handle things in the same thread?
I think there is just one thread.
I assumed Alex meant to check for an invalid stdin before even starting
the TUI thread.
Anyway, I initially wrote this patch (sometime ago) when testing
ShellTUI against Oscar 1.0.2, in situations where I wanted Oscar to
*NOT* run interactivelly. IIRC, the daemon flag is required if:
- the framework is started in the background
- the framework is shutdown not from ShellTUI (e.g. telnet)
This may be the case, but currently I am not sure why it would be. If
you shut the framework down, it doesn't really matter what threads are
active, because all bundles will get stopped and should exit.
We need to investigate the threads being started by the framework and
see which ones are daemon or not and determine what they should be.
There are three threads: event dispatcher (non-daemon), package admin
(daemon), and start level (daemon).
I think my reasoning for making the event dispatcher non-daemon is so
that it wouldn't be interrupted in the middle of delivering events, but
this is probably a non-issue since the framework would be shutting down
anyway.
So, it might be possible to make them all daemon threads. The question
to answer is who should be responsible for keeping the VM from exiting,
the framework itself or the framework launcher?
Then the ShellTUI thread is stuck in the in.readLine() call and the
framework never ends. I'm not sure if this applies to felix.
Yes, that makes sense...perhaps the simple solution here is to interrupt
the thread from the stop() method.
One thing that might be helpful is if we make all threads daemons, then
it would eliminate one source of confusion for people when they start
the framework and it cannot find the shell bundles. In that scenario it
appears that the framework is hung, but in reality it is just running in
the background without an interactive shell.
Do people have an opinion on what is the best approach?
2. Bundles are not supposed to call stop on themselves, so we would
have to change that...we don't really need to stop the bundle, we
can just have it stop processing input.
+1 to this ... that's the core problem.
I'm sure I saw this on other bunldes, so please explain: how should a
bundle stop itself if required ?
It should need to, in theory, it should just go into some
non-functioning or degraded mode; this is the job of the management agent.
I should point out, though, that Felix doesn't check for this, so it is
possible to do.
-> richard
