Want reasonable reference counting? Disable automatic sharing of immutable

Steven Schveighoffer schveiguy at gmail.com
Sat Nov 13 14:34:43 UTC 2021


On 11/12/21 11:36 PM, Stanislav Blinov wrote:
> On Saturday, 13 November 2021 at 03:03:21 UTC, Steven Schveighoffer wrote:
> 
>> This is an odd way to look at it. The finalizers are not run directly, 
>> and maybe not even run on the same thread as the pure function being 
>> run. They also should not be observable (for the most part), because 
>> you should not have access to that data any more.
>>
>> It's like saying an OS context switch that happens in the middle of a 
>> pure function must somehow be valid pure code.
>>
> 
> Not run directly??? As far as I know, GC, on allocation, may hijack the 
> caller to do a collection. Net effect is that it executes arbitrary (not 
> pure, not @safe, etc.) code within caller.

Whether it does this or pushes it off to another thread is incidental. 
The running of finalizers is a function of the GC, not the caller.

This is no different than monads in other languages doing impure things 
initiated by pure functions.

> Caller is marked pure. GC may 
> run impure finalizers that mutate some global state. Something as stupid 
> as call to "close" which may set errno, or, I don't know, freeing half 
> of program state, mutating shared globals... There can be no "for the 
> most part" here. You've got pure function mutating global state. That's 
> something pure functions aren't supposed to be doing.

The part you are not getting is that this is not something being called 
by the pure code, it's being run by the GC. Imagine it like a context 
switch to another thread that runs the GC code, and then switches back 
to the pure code. In fact, the GC could do this ALREADY, because it 
could use one of the other threads that it has paused do the collection. 
But it doesn't really make any difference conceptually which thread runs 
it. One of those other threads could be in the middle of a pure function.

It's similar to running some kernel code, or signal code -- it's 
initiated by a separate entity, in this case the GC.

> Unless that changed and GC isn't doing that anymore, that's a bug that's 
> been open for some years now.

It should be closed as invalid. Which bug is that?

-Steve


More information about the Digitalmars-d mailing list