🚀 go-pugleaf

In article <wade-1909951248440001@bucky.famres.wisc.edu>,
Wade E. Masshardt <wade@macc.wisc.edu> wrote:
>You only have to lock handles when your app calls certain ToolBox
>routines, which are known to move memory (I believe these are marked as
>such in Inside Macintosh.)  Since the MacOS currently uses cooperative
>multitasking, you know precisely where in your code the yield will occur. 
>You should always lock handles before using them, just as good coding
>practice.  You don't have to leave them locked when you yield the CPU,
>unless you yield in the middle of a loop which dereferences the handle.  I
>would suggest that if you have a loop that takes long enough to execute
>that you have to yield in the middle of it that you should probably unroll
>the loop or redesign it somehow.

That all makes sense; but doesn't it strike you as strange that you have
to jump through all these circles just to have a properly written
Mac program? Under other operating systems, you just generate code
that does what you want. Allocated memory stays at the same logical
address.

What if you don't do things right? With all these added complications, it's
not inconceivable that you accidentally dereference a pointer to a location
that no longer belongs to you and clobber some other program's data. Oops.
The whole system is spammed.

Nevin Liber keeps claiming that CMT systems are easier for the programmer
because you don't have to mess around with things like semaphores. If
this is true of the Mac, how do you explain all this memory handle
locking business? Your explanation of what has to be done to write 
a piece of code properly and then fine-tune it for good performance makes
me cringe.

It sounds like DOS talk to me: "...you see, some DOS calls can't be
made from your TSR. Well, you can do it if you watch the "inDOS" flag
and cross your fingers...".
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?