Multi-Thread Application problem

[Steven Schveighoffer]

"Benjamin Schulte" wrote
> Hi,
>
> thanks for your reply. I guess this was the fact I didn't know so far. Is 
> it for the constructor equal?
>
> But yes, I had a sleep in the deconstructor, waiting for the other thread. 
> I then just wonder why it worked sometimes and only a few times it didn't. 
> But maybe there's still another bug in my applcation.
>
> But here's the code - maybe there's still a way to optimize it. But I 
> guess first I need to replace the deconstructor with a free-method 
> deleting itself after freeing the resources.
>
> ThreadCall.doEvents( ) is being called from Thread A.
>
>
>
> class someclass {
> ~this( )
> {
> // Outside-Of-Thread call
> ThreadCall.call( function( uint id ) {
>
> glDeleteBuffersARB( 1, cast(uint*)&id );
> return 0;
>
> }, cast(uint)vboBuffer );
> }
> }

What is stopping you from calling glDeleteBuffersARB from the destructor? 
(I'm assuming glDeleteBuffersARB is a C call).

Aside from that, probably the only good way to do this is to queue the call 
and not wait for the result.  However, it is possible that the semaphore is 
already locked.

I remember someone having a problem with freeing resources by using a C 
function in a destructor, and finding that a lock was held by a suspended 
thread.  I think this problem has been solved in Tango's GC (I could be 
wrong).  You may want to look into that.

-Steve