Re: Garbage Collection

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <35300@think.UUCP>, by barmar@think.COM (Barry Margolin):
> There are several programs running in a common address space.  Call
> them COMMAND_PROCESSOR, COMPILER, and EDITOR.  There is a global data
> structure, COMPILER_WARNINGS; the operations on this database include
> adding warnings, selecting warnings based on various criteria, and
> deleting selected warnings from the database.  COMPILER adds warnings,
> as one would expect.  EDITOR has operations that make use of the data
> in COMPILER_WARNINGS; for instance, you can display the warnings for
> the current file and have the editor position you to the appropriate
> source line.  And COMMAND_PROCESSOR has a command to clear out
> COMPILER_WARNINGS (which selects all warnings and then deletes them).
> 
% The natural way to implement the COMPILER_WARNINGS database is as an
% array or list of pointers to warning structures.  The ADD operation
% copies the pointer it's given, and is documented so that the caller
% knows not to try to deallocate the object it added.  SELECT simply
% returns newly allocated pointers to the selected warnings.  DELETE
% objviously should deallocate the pointer and remove it from
% COMPILER_WARNINGS, but what about pointer.all?
% 
% If someone has called SELECT and it has returned a pointer to a
% particular warning, DELETE should not deallocate pointer.all, because
% there is another handle to it.  EDITOR should be permitted to continue
% to display and manipulate selected warnings even if they've since been
% deleted from the global database.   [...]
% 
% Can this be solved with only documentation?  Or is this an ugly
% example that only a Lisp afficionado would think is clean?

    It's in severe need of a cleanup.

    If I understand the problem correctly, we have a command processor,
    a compiler, an editor, and some set of files upon which the compiler
    and editor are to operate.  When a file is sent through the compiler,
    the compiler generates a warning structure with respect to that file.
    The editor then makes use of these warning structures during debugging.
    Furthermore, a command exists whereby the warning structures for given 
    files are destroyed, and this command must not interfere with editor
    processes which are still alive.

    Let's assume the existence of a suitably implemented warning container,
    which has been appropriately hardened for use as a shared variable.
    Our compiler proceeds by read-locking the file and write-locking the
    warning structure; having acquired the locks, the warning structure
    for that particular file is updated, and the locks are then released.
    Our editor proceeds by write-locking the file and read-locking the
    warning structure, updating the file, and then releasing all locks.
    Our warning destroyer proceeds by write-locking and then destroying
    the specified warning structure(s).

    That was almost too easy.  Did I misunderstand the problem?



                                       Bill Wolfe

                                wtwolfe@hubcap.clemson.edu