DIP 1008 Preliminary Review Round 1

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Fri May 26 18:37:09 PDT 2017


On 5/26/2017 2:31 PM, Steven Schveighoffer wrote:
> "The destructor for Throwable will, if the refcount is 1, call 
> _d_delThrowable(e.next), i.e. on the head of the chained list of exceptions."
> 
> How does this work if the throwable is being destroyed by the GC? In this case, 
> e.next may be a dangling pointer.

The GC calls a finalizer which calls _d_delThrowable on the e.next value.

> "it will call the new function _d_newThrowable() which will allocate E and 
> intialize it for refcounting."
> 
> Where is it allocated?

My implementation uses malloc().

> If on the GC heap,

It isn't.

> how can it be @nogc?

And that's how it can be @nogc.

> If not, then how does it interact with GC pointers?

The refcount of 0 means it is GC allocated.

> e.g. the e.next pointer may point to a 
> GC-allocated exception, how to stop the GC from collecting it early?

The usual way - register the roots with the GC. Take a look at the PRs for this, 
they do that.

> Part of this may mean clarifying what @nogc actually means. Does it mean no 
> interaction with the GC system, or does it mean "cannot run a collection cycle"?

@nogc means no GC allocations occur in the @nogc code, the same as usual, no 
more, no less.

> "In catch blocks, e is regarded as scope so that it cannot escape the catch block."
> 
> If e is scope, then the destructor is called. However, since e is a reference 
> type, the data it points at isn't really stack allocated, and the scope-ness 
> ends at the reference, no? So what if you have something like this?
> 
> void *foo;
> 
> try
> {
>    func();
> }
> catch(MyException e)
> {
>     foo = e.voidptr; // get pointer to some member
> }
> 
> Should foo be allowed to capture pieces of e? How does the compiler stop that if 
> not?

That's what DIP 1000 addresses. DIP 1008 relies on DIP 1000.

> What expectations can e assume in terms of its members that are references? 
> Can it assume that it is in charge of the management of that memory if it's ref 
> counted, or does it need to assume GC usage for those items?

See DIP 1000.



More information about the Digitalmars-d mailing list