Upcall handler

Justin Fletcher justin.fletcher at ntlworld.com
Mon Dec 17 13:58:47 PST 2001


In message <45ac7aea4a.Jo at village.uunet.be>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <f82f48ea4a.Justin at gerph.movspclr.co.uk>
>           Justin Fletcher <justin.fletcher at ntlworld.com> wrote:
>
> > [...]
> > However, these last three suggestions are more in the area of crash
> > prevention, rather than required environment handling (into which UpCall
> > most definately falls).
>
> Can't the Wimp claim the ChangeEnvironmentV vector and when it sees the
> UpCall handler (or any other offending handler which might be called by
> background tasks) being defined in its current swapped in task, replace
> the handler by a routine of its own which does some filtering before
> calling the original handler ?

Whilst it could, why bother ? It wouldn't really solve the problem, just add
a load of useless gumph around the upcall handler routine.

Doing a special case to replace the environment handler when it's been
replaced seems like a lot more hassle than just adding a single TEQ to the
wimp to check for the additional case of the UpCall handler being present or
not.

To recap, the wimp is already replacing the handlers, it doesn't need to
check whether they've been set or not, it just needs to make them safe for
the page out to happen.

-- 
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