Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!endor!singer From: singer@endor.harvard.edu (Andrew Singer) Newsgroups: comp.sys.mac Subject: Re: LSC and MultiFinder/Juggler Message-ID: <2708@husc6.UUCP> Date: Wed, 19-Aug-87 14:50:10 EDT Article-I.D.: husc6.2708 Posted: Wed Aug 19 14:50:10 1987 Date-Received: Sat, 22-Aug-87 02:59:22 EDT References: Sender: news@husc6.UUCP Reply-To: singer@endor.UUCP (Andrew Singer) Organization: Aiken Computation Lab Harvard, Cambridge, MA Lines: 59 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.