Path: utzoo!utgpu!attcan!uunet!husc6!bbn!csd4.milw.wisc.edu!nic.MR.NET!umn-cs!berlin!grg From: grg@berlin.acss.umn.edu (George Gonzalez) Newsgroups: comp.sys.mac.programmer Subject: Re: Stack manipulation problems Summary: Stack usage is funny on the Mac Message-ID: <275@berlin.acss.umn.edu> Date: 6 Jan 89 17:20:06 GMT References: Organization: U of M MicroGroup, Minneapolis Lines: 25 I ran into exactly the same problems when implementing multi-tasking within a program I was writing. I did a lot of head scratching until I peeked at the stack, and some of the ROM trap code. What's happening is that many of the ROM traps assume that they can use the space above the op of the appl heap up to the bottom of the stack for temporary storage. I think UnionRgn is one of the worst offenders, dividing up that space into 3-5 equal sized chunks and putting temporary QuicDraw regions in each chunk. This is OK under normal stack usage, but bad if you have several stacks in the stack area. Some of them will get creamed by the temporary vars. There's also a problem if you created the stacks in the appl heap. Now UnionRgn sees that there's no room below the stack and above the heap, as the stack is *inside* the heap. So it just quietly does nothing. This explains why screen redraws get garbled, as QuickDraw can't do its job. When I asked Apple how to solve the problem, they suggested doing all QuickDraw calls from the bottommost stack (the one that has clear space below it down to the top of the appl heap). So allocate your screen update task *last*, and don't draw from any other task. Ugly, but that's the way it is. It would be nice if Apple cleaned up their stack usage. But this would require new ROM's, so its not likely to happen to fix this problem.