[gccsdk] Threading + Alt-Break = Trashed Computer
lists at snowstone.org.uk
Mon Jul 14 11:55:23 PDT 2008
In message <op.ud7id01fl0n5eg at balaptop.ba>, Ben Avison wrote:
> John Tytgat <John.Tytgat at aaug.net> wrote:
> > In message <op.ud7brttdl0n5eg at balaptop.ba>
> > "Ben Avison" <bavison at riscosopen.org> wrote:
> > > It could be argued that this would be a retrograde step, because
> > > if an application has a rogue exit handler which refuses to
> > > terminate while the task is not the active task, then you would
> > > no longer be able to kill it after such a change.
> > But if we're considering the case of a task with rogue exit handler
> > you won't be able to kill that task when it happens to be the
> > current task. And that's the situation today since RISC OS 3.5. So
> > why are we seeing this as an argument for killing the not-current
> > task ?
> It's true that if the current task has a rogue exit handler then
> you've always been stuffed. (Though as part of my suggested change, I
> think it be good to enable the user to override a rogue exit handler
> for any task, including the current one.)
> What I'm trying to say is that adding a new way for some rogue code to
> crash the machine is not a good idea,
I'm not sure which is worse - some rogue code crashing the machine, or
some perfectly legitimate code (e.g. mine ;) crashing the machine. I
suspect other people will be more worried about the behaviour of Firefox
than my little app though!
What's the way forward for this? Even if the optimum solution does
turn out to be an OS update, is there some interim solution, or can the
OS functionality be updated in a piecemeal fashion? Where does the
watchdog code reside?
> and the user should at least
> retain an option to force a non-current task to be killed (as we have
> had since OS 3.5) if they absolutely demand it.
> If this sounds far-fetched, imagine an application which installs and
> removes some type of handler around calls to Wimp_Poll, and has an
> exit handler which removes the handler. Now imagine that the exit
> handler has a bug that means it goes into an infinite loop if the
> handler isn't installed (maybe it used a non-X SWI to deregister the
> handler and an error is generated, which would then call the exit
> handler again).
At the risk of revealing my ignorance... Doesn't this case depend on a
signal handler invoking the exit handler, which then raises a signal and
so on? In which case this is not possible when using UnixLib as I'm
pretty sure it traps recursion in a signal handler. So there isn't an
existing case where the discussed change would have an adverse effect.
> Now, if the exit handler is invoked when another task
> is active, then from the point of view of the dying task, it's as
> though as OS_Exit was called inside Wimp_Poll - provoking the error
> because the handler was removed for the duration of Wimp_Poll. The
> error could not have been provoked under any earlier Wimp, because as
> far as the task is concerned, Wimp_Poll simply never returned and the
> exit handler was never called.
> > I'm not sure if I fully understand your suggestion. Is it something
> > like the first Alt-Break for a task gets its Exit handler called,
> > and a 2nd Alt-Break the Wimp Exit handler gets called and the task
> > gets killed straightaway ?
> Yes, that's pretty much it. Maybe the user interface could be
> different for the second case - something like "The application is not
> responding, do you want to force a quit"
The UI for the Watchdog could do with some work in general ;)
Adam Richardson Carpe Diem
More information about the gcc