jmm@thoth14.berkeley.edu.BERKELEY.EDU (10/08/87)
In IM, it says that you can't use any routines that access the memory manager directly or indirectly from within things such as VBL tasks, system tasks, etc. Does this mean that any system call that can cause heap scrambles is disallowed? James Moore ucbvax!leggatt!jmm
brian@hpfclm.HP.COM (Brian Rauchfuss) (10/10/87)
/ hpfclm:comp.sys.mac / jmm@thoth14.berkeley.edu.BERKELEY.EDU / 1:41 pm Oct 8, 1987 / >In IM, it says that you can't use any >routines that access the memory manager >directly or indirectly from within >things such as VBL tasks, system tasks, etc. >Does this mean that any system call that >can cause heap scrambles is disallowed? No, it is worse than that, VBL tasks are run during the vertical blanking interval, which is run by an interupt. That means that the system could have been doing ANYTHING when it was interupted. It could have been rearranging the heap, for example, in which case memory manager routines which need to look at the heap are very, very dangerous. In general, it is safe to play with locked down blocks and pointers, and most (all?) commands which do not scramble the heap can be used as long as you are sure the data you pass to them is not moveable. Brian (Smokefoot) Rauchfuss "Hey, lay off man, I'm a scientist"
afoster@ogcvax.UUCP (Allan Foster) (10/11/87)
In article <jade.5365> jmm@thoth14.berkeley.edu () writes: >In IM, it says that you can't use any >routines that access the memory manager >directly or indirectly from within >things such as VBL tasks, system tasks, etc. >Does this mean that any system call that >can cause heap scrambles is disallowed? > >James Moore >ucbvax!leggatt!jmm This means exactly what it says. YOU CANNOT USE ANY ROUTINE THAT USE THE MEMORY MANAGER!!!! The reason for this is that the interupt that started your routine running could have interupted the memory manager in its work. It may be moving the heap around, so the only thing that you can rely on is that any locked handles and pointers will be valid. You cannot even call anything that gets or disposes allocated memory. The state of the momory manager is totally unknown!! Regards Allan Foster. Hey, You can't do that, You're DEAD --The living Daylights Allan Foster UUCP : tektronix!ogcvax!afoster GEnie : A.FOSTER AppleLink : UG0035 USPS : 1340 SE 89 Portland OR 97216 Voice : (503) 257-0573 Voice : (503) 252-1351 CSNet : afoster@Oregon-Grad
lippin@spam (tom lippincott) (10/12/87)
jmm@thoth14.berkeley.edu.BERKELEY.EDU sez: >In IM, it says that you can't use any >routines that access the memory manager >directly or indirectly from within >things such as VBL tasks, system tasks, etc. >Does this mean that any system call that >can cause heap scrambles is disallowed? Yes they're disallowed -- during the interrupt, you could be pulling information right out from under the main program. But wait, there's more! Even calls that don't change the heap can cause problems -- most quickdraw routines, in particular, are not reentrant. If you make a quickdraw call while the main program is making one, you'll probably mess up that call. (I've tried this. The bugs are Mostly Harmless, but there.) In the back of IM III there's a list of things not to call, which is extended in IV, and likely will be in V when it gets finished. But a good rule of thumb is that *no* calls that do any drawing can be called during the VBL interrupt. May the source be with you, --Tom Lippincott ..ucbvax!bosco!lippin "Release the blundering dolts!"
tecot@apple.UUCP (Ed Tecot) (10/14/87)
In article <1319@cartan.Berkeley.EDU> lippin@spam.UUCP (tom lippincott) writes: >But wait, there's more! > >Even calls that don't change the heap can cause problems -- most quickdraw >routines, in particular, are not reentrant. If you make a quickdraw call >while the main program is making one, you'll probably mess up that call. >(I've tried this. The bugs are Mostly Harmless, but there.) No, that's not true. What you are experiencing is completely different: Someone else has already explained that an interrupt can interrupt just about anything, including heap compaction. Of course you don't want to make any memory manager calls at this time, since that could cause heap corruption. However, you also don't want to reference ANY unlocked relocatable blocks, as they could be "in transit". Quickdraw regions are by definition relocatable. So it follows that you don't want to make any quickdraw calls that affect regions. However, every grafPort contains two regions, a clipRgn and a visRgn. So, you don't want to make any quickdraw calls that uses a grafPort. It turns out that only two useful calls remain: CopyBits and CopyMask. But beware: These calls check to see if the destination (pix or bit)Map is the same as that of the current grafPort, and if so, uses the grafPort's clipping. So, in effect, these calls are only useful if the destination is an offscreen (pix or bit)Map. In summary, QuickDraw is reentrant, but it's dependency upon the memory manager precludes its use during interrupt time. _emt
lippin@skippy (tom lippincott) (10/15/87)
Recently tecot@apple.UUCP (Ed Tecot) said: >In summary, QuickDraw is reentrant, but it's dependency upon the memory >manager precludes its use during interrupt time. > _emt Where were you a few months ago when I needed to make use of this? I was only writing a prototype of a program, and I figured that locking down everything in sight and trying this would be safe enough for my purposes. I had a VBL task doing some drawing; I wanted characters, but would settle for lines, or a copybits call. Meanwhile, the main program wanted to draw sometimes. What happens? Whenever the main program is interrupted while drawing over the cursor, it leaves a cursor image lying on the screen. Fine for drawing pine forests, but not good for much else. I eventually tracked this down to the QD cursor globals getting confused, and had the VBL task save and restore them as necessary. Another not-so-good step, but it certainly looks like the calls were *not* reentrant. I hope you're not speaking for Apple on this one. Sorry if I sound a little harsh, but it's just not so. --Tom Lippincott ..ucbvax!bosco!lippin "If it was so, then it would be, and if it were so, then it could be, but as it isn't, it ain't. That's Logic." --Tweedledee
tecot@apple.UUCP (Ed Tecot) (10/19/87)
In article <1329@cartan.Berkeley.EDU> lippin@skippy.UUCP (tom lippincott, ..ucbvax!bosco!lippin) writes: >Recently tecot@apple.UUCP (Ed Tecot) said: >>In summary, QuickDraw is reentrant, but it's dependency upon the memory >>manager precludes its use during interrupt time. >> _emt > > >Where were you a few months ago when I needed to make use of this? >I was only writing a prototype of a program, and I figured that >locking down everything in sight and trying this would be safe enough >for my purposes. How can you guarantee this? Any region call (such as when a window is moved so that it's visRgn changes) could cause a call to SetHandleSize which may relocate the block. I don't know what happens if the block is locked; but it's not good in any case. >I had a VBL task doing some drawing; I wanted characters, but would >settle for lines, or a copybits call. Meanwhile, the main program >wanted to draw sometimes. What happens? Whenever the main program >is interrupted while drawing over the cursor, it leaves a cursor image >lying on the screen. Fine for drawing pine forests, but not good for much >else. > >I eventually tracked this down to the QD cursor globals getting confused, >and had the VBL task save and restore them as necessary. Another >not-so-good step, but it certainly looks like the calls were *not* >reentrant. I hope you're not speaking for Apple on this one. The cursor code may not be reentrant, but the remainder of QD should be. If you are drawing at interrupt time, and I don't think you can do any more than off-screen CopyBits, you probably have to be very careful as not to get in the way of the cursor. I personally recommend that you not draw to the screen at interrupt time; there are clean workarounds to be had. I still stand by my QuickDraw claims (but not as an Apple Representative). (I do not consider the cursor code to be QuickDraw) _emt
blh@VLSI.CS.CMU.EDU (Bruce Horn) (10/19/87)
(I'm not the right person to answer this, but here goes...) Ed: QuickDraw (and the Memory Manager, and the Resource Manager, and the Dialog Manager, and the Font Manager...) is not reentrant. In the same way that the cursor calls are not reentrant, neither is QuickDraw (imagine setting the port in one process, then running another that calls QD). This is the problem that is solved partially by Multifinder, which works hard to save and restore all the appropriate globals. It's not just a matter of saving and restoring globals, either; shared structures would need locks and synchronization. Since Multifinder is non-preemptive, it is much easier to handle the "multitasking", since there is no need for locking the structures (context swaps never occur in the middle of critical areas). I don't know what they do with A/UX, which supposedly allows you to call the Toolbox reentrantly. I suspect that interrupts are turned off at critical times (like when entering the ROM--so it really isn't reentrant). -- Bruce Horn, Carnegie Mellon CSD uucp: ...!seismo!cmucspt!cmu-cs-vlsi!blh ARPA: blh@vlsi.cs.cmu.edu