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))) ]

> 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')

"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
'alloc')

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