Upcall handler

Ian Jeffray ian at jeffray.co.uk
Mon Dec 17 04:37:05 PST 2001


Nick Burrett 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.


How do we know we're in an interrupt?  Checking flags?  Hmm...


> We could perhaps exit the upcall handler early, if we are in an interrupt.

The point is, though, that our handler "code" is called when it's not
there.  When the WIMP hasn't paged us in yet... so some random garbage code
gets called which invariably stiffs the machine.

Peter's fix -- to put the upcall handler in RMA -- is good, because of
course, RMA code is always paged-in and at a static address.  There's then
the issue of what to do once we're in our handler.  Since UnixLib only really
cares about Upcall 256, we can bin everything else quickly at this stage.
Upcall 256 also happens to be 'safe' (ie we CAN call our app code) because
it is only called in the instance when our app is being muted - so the code
is really there.

It's upcalls from stuff like the buffer manager, which can end up calling
our environment upcall handler at any time at all which is the real problem.
This, I am pretty certain, is a bug/misfeature in RISC OS.  :-(

Ian.





More information about the gcc mailing list