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: bobduff@world.std.com (Robert A Duff)
Subject: Re: Reading a line of arbitrary length
Date: 1997/03/06
Message-ID: <E6Lrs8.B9r@world.std.com>#1/1
X-Deja-AN: 223451881
References: <5ds40o$rpo@fg70.rz.uni-karlsruhe.de>
 <JSA.97Mar4154951@alexandria> <E6KxGL.B35@world.std.com>
 <JSA.97Mar5182055@alexandria>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-03-06T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <JSA.97Mar5182055@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>Agree.  These are again good example issues.  Another area would seem
>to be task interaction.

Yes, there are lots of "interesting" issues wrt tasks vs GC.  Much of
the GC research (certainly not all) assumes a single sequential
program.  E.g. in a sequential program, it makes sense for the "new"
operation to check available memory and whatnot, and then perhaps invoke
the GC to do some work.  But that becomes rather more complicated when
there might be other tasks doing who-knows-what at the same time.

Many GC algorithms require all tasks to be in some "safe" place before
the GC can do its thing.  This requires some sort of synchronization,
and making that efficient is not easy.  I'm not sure if that requires
user-accessible hooks, though.

- Bob