To drop or not to drop?

Posted on:January 15 2007

Because people are already speculating about my sudden death, here is a short new blog entry. :) (There'll be a more interesting one tomorrow, I hope)

A frequently asked question I've received several times by mail now: Using irrklang's reference counted objects, when do I have to use drop() and when not?
The answer is very easy: Just as in Irrlicht, you only need to call drop() to an object if you received it by calling a method starting with 'create' or when creating it yourself via the C++ 'new'.
After you don't need the object anymore, just call drop() to let the reference counter handle the object descruction automaticly. There is one little single exception to this rule in irrKlang: If you recieved a pointer to an ISound interface, you always have to call drop() after you don't need it any more. Why?
ISound objects are the only public objects which are pushed and used between multiple threads, and you can never know if another thread already has deleted it in between. That's why ISound is also derived from IVirtualUnknown instead of IUnknown.
So maybe a more future prove rule would be: If you get a pointer to an object derived from IVirtualObject, always call drop() if you don't need it anymore. But don't despair: If you are still unsure, just don't call drop() temporarily. Nothing really bad will happen then, you will only waste some small amount of memory used for storing some file names and positions etc.
IrrKlang will still free huge and critical system resources itself in this situation automaticly behind the scenes. Going to add this to the FAQ soon.


Hes alive ;)

Just kiddin... good to hear something new
2007-01-15 23:34:00

Why not make the reference counting automatic? Having a manual drop() sounds just like Release() in COM & D3D, and their excuse for making it manual was that it's compatible with C as well as C++. If you're aiming at C++ it's much better to just make it all automatic - ie when the reference goes out of scope, it's released. Then you get no double-release or failure-to-release issues or confusion over when / if you have to release. boost::shared_ptr is a good example.
2007-01-16 10:41:00

That would mean that niko would have to rewrite half of irrlicht ;)
2007-01-16 11:09:00

When are we going to rename IUnknown to IReferenceCounter... IUnknown makes no sense... IReferenceCounter...makes sense.
2007-01-16 14:58:00

When I started with Irrlicht some years ago I decided to use manual reference counting instead of smart_pointers for various reasons. Don't know how often I defended this approach since then :) I think the main reason was that if you are using smart pointers, you still have to know about what is happening inside, and you can run into trouble if you don't. If you force people to call grab() and drop() themselves, they are forced to think a bit about it, and no one prevents them to use smart pointers anyway then. :)
irrKlang is using the same interface for simple compatibility with Irrlicht of course. And yep, IReferenceCounter or ..ed would be an idea, originally I planned to populate IUnknown with MetaData-stuff similar to the debugdata in it currently.
2007-01-16 18:00:00

Fair enough, your choice :) We've used an auto reference counter (scope based) for some years without any real problems though, yeah people have to be aware of what they do, but in the grand scheme of things it's harder to make mistakes than it is with manual reference counting, since the default behaviour tends to be 'safe' (no need for docs telling people when / if to Release()). But yeah, nothing is totally idiot-proof ;)
2007-01-16 19:30:00

Is the reference counting used by the [i]ISound[/i] derived class thread safe? If you are calling grab() or drop() from your threads, the reference count needs to be safely managed.
2007-01-17 05:10:00

yep, it is threadsafe. That's why its IVirtualUnknown :)
2007-01-17 07:51:00

Add comment:

Posted by:

Enter the missing letter in: "Internationa?"




Possible Codes

Feature Code
Link [url] [/url]
Bold [b]bold text[/b]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]