Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Help With VBL Tasks
Message-ID: <6347@hoptoad.uucp>
Date: 21 Jan 89 15:47:39 GMT
References: <8343@orstcs.CS.ORST.EDU> <27628@ucbvax.BERKELEY.EDU> <451@internal.Apple.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 27

In article <27628@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP
(David Phillip Oster) writes:
>In addition to all the previous problems, most versions of SetUpA5() look
>at a global variable, CurrentA5, which is not guaranteed to be correct
>under multifinder.

In article <451@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>Tech Note 208 also mentions a problem in that SetupA5 saves the current A5
>on the stack, which screws up some optimizing compilers (eg, MPW C 3.0).
>It suggests that you save the current A5 value in a local place and restore
>it at the end.

However, this doesn't address the fact that you may need a different A5
from the one in CurrentA5, which was David's point.  This may happen in
interrupt driven code that is not switched by MultiFinder.  VBL tasks
only run when their application has the processor, but not so things
like socket listeners or custom interrupt handlers.  I still don't know
any way around this except for stashing a copy of your A5 in
code-relative space, which is explicitly forbidden (with good reason)
by Tech Note #2.  I'm not even sure that Apple acknowledges that this
is a problem; when I pointed it out to David Goldsmith a couple of
years back, he just started shouting angrily....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"The above opinions and suggestions have absolutely nothing to do with
 the little, fat man putting crisp, $100 bills in my pocket."
    -- Alan Vymetalik