[self-interest] simplicity

[Toby Ovod-Everett]

On Thu, Jul 01, 2004 at 06:28:40PM +0100, Ian Woollard wrote:
> Steven Shaw wrote:
> 
> >I wonder what makes most resources unlike memory?
> >
> It's a very different emphasis.
> 
> There's a heck of a lot more bytes than copies of any other resource.
> 
> That means you don't need to be quite so paranoid about releasing 
> memory- holding up deallocating an object for seconds, minutes or days 
> may not matter at all. Failing to deallocate a semaphore for that long 
> is likely to damage the system, perhaps fatally.
> 
> > Maybe it's that most 
> >resources are held for short periods of time (although they say the same 
> >about memory...). Probably it's more something to do with the number of 
> >references to a resource. If anyone knows the answer please chime in.
> >  
> >
> Memory is often allocated/deallocated at extremely high rates. That 
> means it *has* to be efficient. Other resources rarely call for the same 
> degree of performance, but do need to be deallocated promptly.

Interesting.  The problem is that as a programmer, I desire to use the same
semantics that let me sweep memory management issues under the carpet (i.e.
automatic memory management that lets me avoid issues of forgetting to release
memory) to address similar issues I encounter with resources.  In systems that
have deterministic memory management (i.e.  refcounting, barring issues with
cycles), it is possible to hide the resource management issues by using the
memory management system.  In effect, we're repurposing the memory management
stuff to handle the resource management stuff.  The problem is that we're
mixing metaphors, and while the two match up reasonably well in a refcounting
system, garbage collection solves the memory management issues better than
refcounting but doesn't solve the resource management issues.

Hmmm.

Points to consider:

* Under Unix and similar OSes (Win32, VMS I think, etc.) that have processes
  (not the only way to structure an OS, BTW), an exiting process cleans up all
  of the memory allocated to it as well as the resources allocated to it.
  This encourages people to think of them as similar things.  It also
  complicates both memory management and resource management because leaks in
  either may not be evident in short running code and may later become an
  issue when the code runs for an extended period.

* Both memory and resources are shared resources across a system, and
  non-deterministic memory/resource managers may not play well with others.
  For instance, it would be good if the OS could say to processes, "Hey, can
  you release some memory - things are getting a bit tight."  Similarly, it
  would be good if the OS could say similar things to processes regarding
  resources (open file handles, semaphors, etc.).

* Processes can share memory in modern OSes.  Some sorts of resources they can
  share, some they can't.

* Many of the troubles we get into with "resources" like files, registry
  handles, etc. is because we're actually using them as a poor man's IPC
  system to send messages between systems, etc.  Better, more secure, easy to
  use libraries with low overhead and so forth for dealing with these issues
  might help us because we'd be doing less misusing of metaphors.

* We really need to design completely new OSes from the ground up.
  Filesystems made sense 30 years ago.  They're no longer an appropriate
  metaphor for dealing with and interacting with data, IMHO.  Of course, Jecel
  groks all of this brilliantly, at least from the stuff I've seen about the
  design of Merlin.

* If we redesigned our OSes, perhaps we'd have fewer problems with our
  languages.


--Toby Ovod-Everett