🚀 go-pugleaf

In article <446ofvINN97n@keats.ugrad.cs.ubc.ca>,
Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:
>I wonder how many Mac programs assume that the system is cooperative, and
>don't bother locking handles when they "know" that they will have the CPU.

>This is why I mixed up the issue of coopeative multi-tasking and global
>heap management in one post; you criticized me for doing so, but I felt
>it was justified.  The two are not decoupled in the Mac operating system.
>The heap management, in its current form, couldn't function under pre-emption.
>I suppose that if each application is given a separate, virtualized Mac,
>there won't be a problem.

Many applications do assume that. However, this has an impact with
pre-emption only on references to the system heap (which is shared among
all applications). The situation is actually better now than in the original
MacOS since desk accessories shared the application heap.

This whole argument seems to be missing the point, though. The reason for
having a memory allocation scheme built in to ROM in the first place wasn't
to allow programs to allocate and de-allocate memory easily, but to allow
the operating system to allocate and de-allocate memory within the
application's heap without interference. It was also a substitute for
demand-paged virtual memory to the extent that resources could be
automatically purged and re-loaded from disk as necessary.

The real reason for handle-based memory allocation, as opposed to other
types, is not that it gives you the ability to compact/purge memory,
but that it lets the operating system have objects that can change size.
Any memory allocation scheme the application is going to use must be
compatible with how the OS (or any libraries) use it. For example,
if you don't use malloc() memory management, you'd better not use any
of the library routines that allocate space using malloc() (such as strdup()
or some others).

If you, as an application programmer, want to do your own memory management,
just allocate pointers rather than handles. The only time you have to use
handles is when dealing with those parts of the OS that need them (and
typically, those are parts where handles make sense - the object may change
size, e.g. a region).
-- 
Steve Peltz
tricorn@uiuc.edu