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