From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!ames!ncar!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Garbage Collection
Message-ID: <4054@hubcap.UUCP>
Date: 10 Jan 89 02:50:24 GMT
References: <35300@think.UUCP>
Sender: news@hubcap.UUCP
Reply-To: billwolf@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>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