RFC: safe ref counting

Steven Schveighoffer schveiguy at gmail.com
Sat May 2 18:16:13 UTC 2020


On 5/2/20 7:14 AM, Seb wrote:
> On Saturday, 2 May 2020 at 02:27:10 UTC, Steven Schveighoffer wrote:
>> In trying to make iopipe @safe, I came to the realization that having 
>> auto-managed items such as files and the like (std.io Files and 
>> Sockets are non-copyable), you need to rely on some form of @safe 
>> reference counting. Unfortunately std.typecons.RefCounted is not and 
>> cannot be safe. This is because it allocates in the C heap, and 
>> deallocates regardless of whether anyone has ever squirreled away a 
>> reference.
>>
>> [...]
> 
> Are you aware of the stalled work to get reference counting in druntime?
> 
> https://github.com/dlang/druntime/pull/2679
> 
> https://github.com/dlang/druntime/pull/2646
> 
> https://github.com/dlang/druntime/pull/2760

No, but these are not what I'm focused on.

I want a @safe API, I don't care about @nogc in iopipe. The problem with 
letting the GC clean up your non-memory resources is that it may never 
happen, or it may happen at a much later time. A process can have a lot 
of memory, it's open file descriptors are much more limited.

But the memory used to implement said resources I'm fine leaving to the 
GC to clean up. In other words, I want my files to close as soon as I no 
longer need them, but the shell being used to store the file info (e.g. 
buffer etc) can stick around while something has a pointer to it.

I don't know if reference counting without GC can be made safe for D.

ikod has a good plan, don't give access to the actual data. But it falls 
apart in practice, because then you can't use standard functions, 
everything has to use reference counted pointers and arrays. Not only 
that, but a generic library can easily give away the data without you 
wanting it to. You have to be really cautious about how you use the 
reference counting.

I like the plan of letting the GC ensure the memory is always valid. I'm 
just not sure about the problem of cycles. That's the one place this 
might fall down.

-Steve


More information about the Digitalmars-d mailing list