Hi Brad, Adding a catch in osgDB::Registry might be something you could explore. A custom Registry::ReadFileCallback could allow you to do this without making intrusive changes to Registry or the DatabasePager. Generating an error message and returning NULL would be sensible.
As for trying to add extra intelligence in DatabasePager to try and cope with out of memory conditions, I don't personally think that this is worth the effort, it'd add a lot of complexity and in the end will be always kicking a solid wall - the problem is still there, and stemming from elsewhere in the overall application/database set up. The problem without running out of memory really has fixed at a high level, you need to profile you app and database to find out why its running out of memory. Typically paged databases run at quite lower overhead as they are able to load balance, if you are running out of memory then something is wrong somewhere. Robert. On 3/22/07, Bradford, Chase <[EMAIL PROTECTED]> wrote:
So, if something happens that causes a bad allocation, the database pager thread will die, because it doesn't handle the bad_alloc exception thrown by operator new. Unfortunately, all of the information you gave me about NULL return values is moot because unless new is called with a nothrow argument, you won't get a return value on a bad allocation. Would it be possible to make the pager report an error instead of unwinding out of run()? That way we make attempts to free. In most cases, I don't think insufficient memory would be catastrophic because if I had some way of knowing about the error, then I could pause the pager for a bit, free some cached objects, decrease cache sizes, force extra culling, etc, then make a second shot at loading models. If nothing else, I would at least be able to log the error before my application fails completely. Keep in mind ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Thursday, March 22, 2007 11:13 AM To: osg users Subject: RE: [osg-users] bad_alloc in DatabasePager thread The new will return NULL when ever a fail to alloc the memory and typically if your not catching this with a try/catch block or simple if Pointer = null test then your app may run until you use the pointer ( or it may not simply die) or you have bad allocs set to throw an exception in your compiler Typically in scenegraph a try and catch blocks are rearly used due to the over head they can introduce, so you paying Peter to rob Paul sort of thing, your shooting for speed and hit a bad alloc typically means you process/app is doomed at that point ( not always but mostly) Best Regards Gordon __________________________________________________________ Gordon Tomlinson Email : gordon.tomlinson @ overwatch.com YIM/AIM: Gordon3dBrit MSN IM : Gordon3dBrit @ 3dSceneGraph.com __________________________________________________________ Telephone (Cell): (+1) 214-477-8914 Telephone (Work): (+1) 703-437-7651 "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bradford, Chase Sent: Thursday, March 22, 2007 12:49 PM To: osg users Subject: [osg-users] bad_alloc in DatabasePager thread Hi Everyone, I'm trying to find out what happens when the new operator fails in a reader plugin due to insufficient memory. I don't see any catches for std::bad_alloc, or std::exception even, so if something like that happens, will the call stack unwind until DatabasePager::run() is left? I'm assuming that there are some guards against a failure like that, but I don't see any, and I'm worried that it might cause problems for us given the size of the scenegraph we are trying to load. Thanks, Chase _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
