Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!gatech!rutgers!dayton!mmm!olson From: olson@mmm.UUCP (Al Olson) Newsgroups: comp.sys.mac Subject: Re: turning off the stack sniffer (long) Message-ID: <1370@mmm.UUCP> Date: Tue, 7-Jul-87 15:36:12 EDT Article-I.D.: mmm.1370 Posted: Tue Jul 7 15:36:12 1987 Date-Received: Sat, 11-Jul-87 00:43:34 EDT References: <1289@briar.Philips.Com> <135@cantuar.UUCP> Reply-To: olson@mmm.UUCP (Al Olson) Organization: Software & Electronics Resource Center/3M Lines: 50 Keywords: stack 60 Hz multitasking HeapEnd trap dispatcher dirty illegal Summary: There is another way... (long) I have also been playing around with "multi-tasking" on the Mac and ran into the some of the same problems. I discovered that placing a process stack in a heap block causes major-league problems. (The MoreMasters trap also looks for heap zones on the stack in its search. Blammo!) This approach gave me so much grief that I did the only logical thing -- I gave up. Well, not completely. The Mac firmly believes that the stack is the stack and the heap is the heap, so why fool it? I tried another approach which works faily well - link the process stack on to the scheduler stack a context switch. Where does it come from? When a process is prempted (either synchronously or asynchronously), copy the process portion of the stack (including registers, etc) into a newly allocated heap block. Then save the handle in the process descriptor. Now deallocate the process stack and restore the scheduler. This is nice because when a process is not executing its saved stack relocates in memory. When resumeing a process, do the reverse: create space on the scheduler stack, copy the proc stack in and throw the block away. (of course you have to lock the handle during transfer). This method has the advantage of keeping the stack and the heap seperate and allowing the stack sniffer to work *for* you. The disadvantage is the increased time to perform a context switch. (the BlockMove trap is pretty damn fast though). Process premption and toolbox reentrancy is another issue, however. I approached this in a slightly different, but equally illegal way. After a few sessions with Tmon, I discovered the format of the stack during the execution of a VBL task. Way down deep, but in a fixed location, lie the SR and PC value pushed during the exception by the 68000. Now what? Prior to entering the scheduler, I located and locked the resource map for the application (scheduler + processes) ank kept a pointer to the CODE resource list. During my VBL task I compare the interrupt PC value with all loaded code segments. If the PC lies in a loaded CODE segment (not the scheduler's, however) then I *replace* the interrupt PC and SR with my own premption routine. (after saving them, of course). The result: asynchronous premption. The only real advantage of this method is that I have not patched *any* trap routine. (although blasting the stack is certainly more severe) I guess there is no easy way to initiate asynchronous premption without resorting to subterfuge... Any way, these are just some thoughts I had on the subject. Maybe I should wait for a Mac II and Unix... -- Alan Olson ihnp4!mmm!olson