🚀 go-pugleaf

In a previous posting, "rs4u+@ANDREW.CMU.EDU (Richard Siegel)" wrote:

> Just a comment -- Chuq (awesome dood :-) mentioned that LSC had problems
> under Juggler, uh, MultiFinder.
>
> 	This is an understatement. Lightspeed C *crashes* under Juggler...

The following was posted this week on CompuServe. I post it here in its
entirety to help clarify the above.

   Jon Hueras
   THINK Technologies, Inc.

--------------------------------------------------------------------------

#: 55760 S3/Mac Programming
    15-Aug-87  18:59:22
Sb: Multi-Finder bug
Fm: Michael Kahl 75236,3146
To: All

In attempting to determine why LightspeedC crashes under the newly
christened Multi-Finder (aka J------), I believe I have found a bug
in Apple's context-switching code.  I can't say yet whether this is
the only thing keeping LSC from working, but I thought I'd report
what I've found in case it's of use to anyone else (and in hopes
that Apple might fix it!).
        
When LSC calls GetNextEvent (or ModalDialog, which in turn calls
GetNextEvent), the Finder gets in to update its windows.  A context
switch is performed to establish a background execution environment.
When the Finder completes this background processing, another context
switch restores LSC's foreground execution environment.
        
During this second context switch, *AFTER* the foreground task's dispatch
table has been restored, but *BEFORE* other low-memory globals (notably
"CurrentA5") have been restored, the context-switch code issues a call
to _SetHandleSize.  This means that if the foreground task has installed
its own _SetHandleSize handler (using _SetTrapAddress), that handler now
gets in, EVEN THOUGH THE CONTEXT SWITCH IS NOT YET COMPLETE!  In particular,
"CurrentA5" still points to the background task's A5 world.
        
As fate would have it, LSC does indeed intercept _SetHandleSize.  The
handler wants access to LSC's globals, but since "CurrentA5" is wrong,
mayhem inevitably ensues.
        
Once it has restored the dispatch table, the context-switch code should
assume that the foreground application can get in on any trap.  Ideally
no traps should be issued until the context switch is complete.  At the
very least, any traps should be called directly (via addresses previously
obtained from _GetTrapAddress) rather than going through the dispatcher.
        
I hope it is safe to assume that this bug report will reach Apple by
virtue of being posted here.  If someone from Apple could acknowledge
this, it would save me the trouble of submitting this through more
official channels.
        
Michael Kahl 75236,3146
THINK Technologies, Inc.