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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5997b4b7b514f689
X-Google-Attributes: gid103376,public
From: jsa@alexandria (Jon S Anthony)
Subject: Re: Reading a line of arbitrary length
Date: 1997/03/05
Message-ID: <JSA.97Mar5182055@alexandria>#1/1
X-Deja-AN: 223380573
Distribution: world
References: <5ds40o$rpo@fg70.rz.uni-karlsruhe.de>
 <JSA.97Mar3141341@alexandria>
Organization: PSI Public Usenet Link
Newsgroups: comp.lang.ada
Date: 1997-03-05T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <E6KxGL.B35@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> hooks should be standardized as well.  Probably performance-tuning hooks
> are "transparent" in Robert's view, and I would agree, but the
> programmer would still like to know how to spell the "Please GC now"
> command, for example.

Right.  This is certainly one such example.


> There are some interesting interactions between finalization and GC.
> The simplest answer is that any object with controlled parts is "live",
> so the GC can't collect it.  But that's not what people want, I think.
> At least not all the time.  (Maybe only for non-limited controlled
> things?)  People probably want the GC to finalize things just before
> reclaiming their storage.  But this opens up various issues: What if the
> Finalize routine takes an otherwise-dead object, and resurrects it by
> planting a pointer to it somewhere?  What if the Finalize routine calls
> a non-reentrant procedure, and the GC decides to call Finalize at an
> embarrassing time?  Are there any constraints on the order in which
> Finalize routines get called in a case where several heap objects become
> dead at the same time?  A standard for a GC'ed Ada would certainly need
> to address these issues.

Agree.  These are again good example issues.  Another area would seem
to be task interaction.

> Somebody else mentioned the other area in which GC is not transparent:
> interfacing to other languages.  Garbage collection is a global problem,
> so if just one small part of your program is written in, say, C, then
> the programmer needs to know whose responsibility it is to deal with
> pointers from the C side to the Ada side.  Is the GC conservative?  Or
> does the user have to ensure that any such pointer is duplicated on the
> Ada side?

That would be Fergus, and certainly for Ada (Interfaces.* and all)
this is another area.


> model of storage usage.  Or else one would need to rely on untestable
> "requirements", which has worked fine for Lisp and Eiffel and lots of
> others.

Agree.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com