Upcall handler

Justin Fletcher justin.fletcher at ntlworld.com
Mon Dec 17 04:43:13 PST 2001

In message <m3heqqvyog.fsf at nick.ws.noc.dsvr.net>
          Nick Burrett <nick at dsvr.net> wrote:

> Peter Naulls <peter at chocky.org> writes:
> > Reply from Kevin Bracey:
> >
> > "There were added in RISC OS 3 a number of buffer UpCalls that are
> > actually called from interrupt routines. This is a Bad Thing(TM) - they
> > should have been events. As a result, an UpCall handler may be being
> > called from interrupts - I suggest you take care.
> >
> > Apart from that, I can't think of any other reason why UpCalls are a bad
> > thing per se."
> If we are in an interrupt, then do you think exiting the upcall handler
> without doing anything could be a suitable workaround.
> We could perhaps exit the upcall handler early, if we are in an interrupt.

AIUI, you can't identify that you're in an interrupt though.

For example, BufferManager triggered on interrupt, issues OS_UpCall
triggering UpCallV, and the first that happens is that you end up in SVC
mode (not IRQ mode) and have no idea that you came from IRQ mode. And you
can't backtrack the stack to find the old PSR, because there might be
post-trap handlers present.

Ok... More investigation implies much more scariness that I was expecting,

Consider sequence:

-> into Wimp
   Lots of pre-Poll checks, filtering and other such bits.
   Call page out routine
   -> Check that the task really is alive
      Loop over all the event handlers, reading the handlers and storing
    * EXCEPT for Escape and Event which are ALSO set to the default handlers.
      Page task out.

The exception is VERY important. Otherwise we'll page out a task that can
have its event handlers called. I believe this code to be the cause of our
failures - the upcall handler isn't replaced, we call it, nastiness ensues
as we no longer have a task.

  It will be very costly to fix earlier OS versions because of the diversity
  of Wimp versions. This fault affects a very small proportion of
  applications, and they will all fail in the same way.

  A solution I may implement unless someone else has a pressing desire for
  it, or a better suggestion, would be to replace OS_ChangeEnvironment
  on known failure Wimps and identify the failure case within the Wimp
  and restore the default handlers from it. This is non-trivial, and relies
  on pattern matching the WindowManager module for that call. It may not
  be a viable solution. It also feels nasty.

  Another solution is a re-issue of the WindowManager module for softload.
  That seems very unlikely, except with Select.

A full solution for new versions of the module would be to check for :
  Unused SWI

I add unused SWI, because any claimant of that as part of the application
could also cause a failure if it happened from the background (eg
application is probing something regularly on interrupts and the module
isn't present).

The Error handler shouldn't need resetting, because nothing operating in the
backgound should ever be calling non-X SWIs. It might not hurt to reset it
though - that would need more thought than the five minutes I've just given

If we were going to the lengths of setting others, it may also be useful to
reset the Data abort, and Undefined instruction handlers too, in case the
application has set those and an interrupt does nasty things.

However, these last three suggestions are more in the area of crash
prevention, rather than required environment handling (into which UpCall
most definately falls).

Kevin probably has some other ideas on this, but I believe that my synopsis
of the reason for the failure is accurate.

If you could keep me informed of anything else that ocurrs along these
lines, I would greatly appreciate it.

Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.

More information about the gcc mailing list