Re: Reading a line of arbitrary length

[jsa@alexandria (Jon S Anthony)]

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