Feature request: guardian-try-collect Daphne Preston-Kendal (30 Nov 2023 23:33 UTC)
(missing)
Re: Feature request: guardian-try-collect Daphne Preston-Kendal (01 Dec 2023 07:56 UTC)
Re: Feature request: guardian-try-collect John Cowan (03 Dec 2023 05:16 UTC)
Re: Feature request: guardian-try-collect Daphne Preston-Kendal (03 Dec 2023 09:45 UTC)
Re: Feature request: guardian-try-collect John Cowan (03 Dec 2023 17:51 UTC)
Re: Feature request: guardian-try-collect Daphne Preston-Kendal (04 Dec 2023 12:19 UTC)
Re: Feature request: guardian-try-collect Marc Nieper-Wißkirchen (14 Dec 2023 15:06 UTC)

Re: Feature request: guardian-try-collect Daphne Preston-Kendal 04 Dec 2023 12:18 UTC

On 3 Dec 2023, at 18:51, John Cowan <xxxxxx@ccil.org> wrote:

> On Sun, Dec 3, 2023 at 4:45 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
>
>> Marc’s proposal seems to be to block the thread until the next garbage collection happens to run anyway. Mine is to request an immediate garbage collection without ‘blocking’ in that sense. I think mine is the better solution since it does not depend on threading to work.
>
> I don't understand that.  In a single-threaded implementation, -try-collect would have to block, as the mutator and the collector can't run concurrently.  It would be different from -wait only if the collector runs in its own thread, so it is "dependent on threading".

We do not usually consider garbage collection to be a ‘blocking’ operation in this sense, though. By this definition, every consing procedure is blocking (since a memory allocation that asks for more than is currently available in the memory manager’s pool of free memory is the most common trigger of tracing and freeing in most GCs).

Daphne