🚀 go-pugleaf

In article <nevin-2509950235210001@mac-nevin.cs.arizona.edu>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <4444pkINNm49@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
>(Kazimir Kylheku) wrote:
>
>> In article <nevin-2309950419270001@mac-nevin.cs.arizona.edu>,
>> Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>
>> >No.  Unlike you, they had practical problems to solve.  You stating that
>> >it wasn't a problem doesn't make it so.  You *still* haven't posted a
>> >solution to what to do if the heap is so fragmented that you can't satisfy
>> >an allocation request, other than quitting the app or buying more
>> >hardware.
>
>> You can block the process until the request can be satisfied.
>
>The heap is fragmented.  There is no more space.  What the hell are you
>going to wait for, Pinhead?  Someone to buy you another disk drive or more
>RAM and hot swap it in while you are blocked?

No, you wait for another process to make the memory available. This isn't
a good solution, because there may be no other process that can or
will make the memory avaiab le, that's why I mentioned the possibility
of an exception mechanism instead. 

Let's watch it with the name calling, all right?

In any case, blocking is preferable to crashing the machine, which is
the Mac way of opting out more often than not. Unwritten buffers be damned!

>> You can
>> raise some sort of exception and let the process handle it in whatever
>> way it wants (including the option to try to restart the request).
>
>In practical terms, people don't handle this case without system or
>library support, as it adds far too much complexity to the code.  If the
>heap is fragmented, you have three choices:  do nothing, compact the heap,
>or find more space.  Saying that it is the application's problem, and not
>the system's problem, doesn't make the problem go away.

Handling exceptions is trivial and elegant (at least it can be). You have
one extra function that is called asynchronously. When that function exits,
the context will be restored and the request will be tried again.
The function can decide to do something, like save critical data, warn
the user, etc. This isn't particularly complex at all, and is centralized
to one module.

>> In any case, you have saved space by not bloating your code with silly
>> wrappers around an overzealous global heap management scheme.
>
>Then you bloat your code trying to find more space, or doing explicit heap
>compaction.  Or you do what most programmers do, decide that the
>complexity of the problem isn't worth handling; the users always manage to
>cope no matter how badly they program.
>
>I'll ask you again:  what would you, as an applications programmer, do
>when your heap is so fragmented that you cannot get a contiguous block of
>memory that you need?  This situation can happen on almost any allocation
>request, so your solution had better be a general one.  And no coping out

There is no general solution, so I wouldn't try to force one particular
method on the application programmer.  Some programs can get by by just
bailing out.  Others may beed to roll back some critical states.  For
instance, an accounting program might want to cancel a transaction.  I
think that the exception method would provide the programmer with enough
capability to perform anything from a trivial abort to a more complex
recovery without complicating the code with needless checks.

>by saying that it isn't your problem or that you'll abort and let the user
>get stuck with dealing with it.

So what to Mac programmers do to handle the case when allocation fails even
after compaction has been done? Most programs I have seen simply bomb the
entire machine. I ran a UUCP gateway program on a Mac that wouldn't survive
the weekend. When the feed got backlogged, the program would get swamped
and spam the whole machine. I increased its partition size, but this ate
several megabytes of RAM even when not using it. Is this what you mean
by letting the user deal with problems? Incidentally, the problem was
solved with the acquisition of another Macintosh to run the program.
Way to go!  The cheap way to do multitasking and memory management!  But
hey, it's what the market wants.  After all, if you want to toast eight
slices of bread, you have to get another quad toaster or a big toaster
oven, right?  And a computer is like a toaster, therefore...
-- 
PGP key id is 0xD3C7995D.
Molybdenum 95! Got your ounce of fission byproduct yet?