www.digitalmars.com         C & C++   DMDScript  

D - Any limitations on how long a destructor can run?

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ok, I know that many (including myself) will argue that the following is
heinous code.  But is it legal?  What are the side effects?

As I see it, the GC thread is calling the destructor, meaning we're
blocking any further GC, plus we're blocking the thread that made the
memory allocation call that caused the GC to run.  Can other (unblocked)
threads run the GC if this blocks for a long time?  If not, what happens
to them if they try to allocate memory when the GC normally would have
run?

class MySocketProtocolClient
{
    ... <ctors and other stuff>

    ~this()
    {
        SendProtocolShutdownMessage();
        WaitForResponse();    // could block for a very long time
        return;
    }
}

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jan 29 2003
parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
 Ok, I know that many (including myself) will argue that the following is
 heinous code.  But is it legal?  What are the side effects?

 As I see it, the GC thread is calling the destructor, meaning we're
 blocking any further GC, plus we're blocking the thread that made the
 memory allocation call that caused the GC to run.  Can other (unblocked)
 threads run the GC if this blocks for a long time?  If not, what happens
 to them if they try to allocate memory when the GC normally would have
 run?

If I remember correctly, the D GC is not a separate thread, but may be called as a side effect of allocating memory. Therefore in effect you're blocking another thread that is making an 'alloc' call. AFAIK there is no guarantee about timeliness of this call, no guaranteed latency (if you want RT you should pre-allocate everything you need, mentioned somewhere in the D documentation). As an implementation issue, the GC algorithm itself should not hold any locks when it calls a destructor. That way the destructor can safely block and not prevent any other threads from executing GC (when they call 'alloc')
Jan 29 2003
parent "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b18ooj$1c8p$1 digitaldaemon.com...
 As an implementation issue, the GC algorithm itself should not hold any
 locks when it calls a destructor. That way the destructor can safely block
 and not prevent any other threads from executing GC (when they call

For the time being at least, destructors should not block on anything.
Feb 17 2003