Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ux1.cso.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Handles and Virtual Memory
Message-ID: <18300010@ux1.cso.uiuc.edu>
Date: 29 Dec 89 17:30:22 GMT
References: <9415@hoptoad.uucp>
Lines: 46
Nf-ID: #R:hoptoad.uucp:9415:ux1.cso.uiuc.edu:18300010:000:2432
Nf-From: ux1.cso.uiuc.edu!hirchert    Dec 29 11:20:00 1989


Steve Dorner (dorner@pequod.cso.uiuc.edu) writes
>Handles are a pain for programmers; they clutter the code, making applications
>not only harder to write, but harder to comprehend and debug.  That translates
>into bugs, which either surface in finished applications, or delay the release
>of nifty things.
>
>I for one would rather see the VM system take a few more hits, and applications
>have a few less bugs.  Down with handles!

It seems to me that the problem is not with the use of handles, but with their
abuse, especially the failure of the languages in use to reflect the
abstraction behind handles.

Many of the problems cited stem simply from the fact that there is no way to
tell the compilers to defer dereferencing of a handle until after a system call
or procedure call has taken place.  Others would be eliminated if the standard
mechanism for locating objects (especially procedure arguments) were a handle
and displacement rather than a pointer, so that determination of the actual
location of the object could be deferred.

With these changes in abstraction, many of the current situations that
"require" locked handles could be handled perfectly well without locking.
Eliminating the "necessity" of locking would eliminate much of the difficulty
in writing code involving handles, most of the clutter in that code, and
eliminate the latent bugs by letting the compiler recognize the necessary
constraints and deal with them automatically.

Locking handles would be appropriate only when one felt one was taking too much
of a performance hit because of the deferred dereferencing.  Even here, the
language could support notations that would allow the compiler to generate the
getstate, lock, and setstate automatically, as well then optimizing the
generated code.

I suspect that with a little cleverness, these concepts could even have been
incorporated into a standard language like C or Pascal.  Unfortunately, none
of the vendors have chosen to do so, so programmers end up having to work
around the limitations of the compilers.

Complaining about handles as a means of managing storage because of these
problems is a little like complaining about screws as a means of holding
pieces of wood together because it is so hard to hammer them in.  The real
problem is that you don't have the right tool for using them.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications