No more crash in debug ! :) Good work ! On Mon, Jun 16, 2008 at 11:18 AM, Serge Lages <[EMAIL PROTECTED]> wrote:
> Hi Robert, > > Currently building the SVN trunk and I get this warning : > > 1>D:\OpenSceneGraph\include\osgDB/DatabasePager(348) : warning C4099: > 'osgDB::DatabasePager::RequestQueue' : type name first seen using 'class' > now seen using 'struct' > 1> D:\OpenSceneGraph\include\osgDB/DatabasePager(312) : see > declaration of 'osgDB::DatabasePager::RequestQueue' > > I'll let you know if everything works fine when the build will finish. > > > On Sun, Jun 15, 2008 at 7:58 PM, Smeenk, R.J.M. (Roland) < > [EMAIL PROTECTED]> wrote: > >> Hello Robbert, >> >> The SVN version is missing the changes (ReadQueue definition) to the >> Databasepager header file. >> >> -- >> Roland >> >> > -----Original Message----- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED] On Behalf >> > Of Robert Osfield >> > Sent: zondag 15 juni 2008 18:03 >> > To: OpenSceneGraph Users >> > Subject: Re: [osg-users] New Improved DatabasePager,now with >> > even more threading! Please take a taste today :-) >> > >> > Hi Guys, >> > >> > While away on training last week, we came across the Windows >> > debug build reporting problem in std::sort and find calls, >> > and investigations into the issue suggested that it was down >> > to the cull thread modifying the DatabaseRequest fields at >> > the same time that those same fields were being used inside >> > the std algorithms being run by the DatabasePager threads. >> > The worst thing that would actually happen is that very >> > occassionally the list would be sorted into incorrect order, >> > but this in itself would only lead to a slightly sub-optimial >> > ordering of loading tiles, it shouldn't actually break any >> > app - so it's really more of an issue with the debugger being >> > overly strict rather than having a serious race condition >> > that would cause real problems. >> > >> > However, even having a benign, occasional, slightly >> > sub-optimal ordering is a problem if end users under Windows >> > are going to keep stumbling over this issue to due to >> > compiler debugging screaming that there is a serious problem >> > and crashing - so it's a community support problem rather >> > than actual a real problem for proper applications, but >> > having more support than we already have is an issue so I've >> > gone ahead and found a solution. Now checked into SVN is an >> > addition of a mutex lock on the current queue that a >> > DatabaseRequest is a member inside the code that updates the >> > DatabaseRequest parameters. This fix should prevent the >> > problems appearing under VisualStudio debug build, it alas >> > will also mean that all users will have to pay the cost of >> > an non essential mutex lock. >> > >> > Could you guys do an svn update and let me know how things go. >> > >> > Robert. >> > >> > >> > On Fri, Jun 13, 2008 at 10:48 AM, Serge Lages >> > <[EMAIL PROTECTED]> wrote: >> > > Hi James, >> > > >> > > I tried to look to this problem but can't find anything, >> > moreover it >> > > seems to work without problems in release (I'll try to make some >> > > stress tests soon to be sure). >> > > >> > > On Fri, Jun 13, 2008 at 1:02 AM, Lynch, James >> > <[EMAIL PROTECTED]> >> > > wrote: >> > >> >> > >> I'm having a similar issue with >> > >> DatabasePager::RequestQueue::takeFirst() >> > >> >> > >> (osg trunk, Debug build, windows XP VS2005). I'm getting some >> > >> assertion errors at _requestList.sort ("sequence not >> > ordered"). Even >> > >> after adding the updateBlock(). >> > >> >> > >> >> > >> I'm pretty new to this code section, so I'm probably off >> > base here: >> > >> Is it possible that the state of the databaseRequest >> > objects within >> > >> the list are being updated (from other threads) during the sort? >> > >> >> > >> IE. If the _timestampLastRequest or _priorityLastRequest >> > are changing >> > >> during the sort, the sort could become unstable. >> > >> >> > >> >> > >> _______________________________________________ >> > >> Jim Lynch >> > >> >> > >> -----Original Message----- >> > >> On Tue, May 27, 2008 at 12:08 PM, Tim Moore <timoore at redhat.com> >> > >> wrote: >> > >> > >> > >> > Indeed. I've made the necessary changes to FlightGear, >> > and it seems >> > >> > to be working fine. >> > >> >> > >> Except for being a cpu hog. >> > >> >> > >> Apparently, the pager thread is not blocked properly and >> > continuously >> > >> spins. The fact that the queue is empty is confirmed by the debug >> > >> messages printed after the block call: >> > >> HANDLE_NON_HTTP 0: _pager->_requestList.size()= 0 to delete = 0 >> > >> >> > >> I have been trying to find the place where the blocking is >> > >> re-established when the queue goes empty, but could not >> > find it. So I >> > >> added an updateBlock() call at the end of >> > >> DatabasePager::RequestQueue::takeFirst that seems to fix the issue. >> > >> Could have added the call within the if-block, but this has the >> > >> additional benefit of stopping runaway loops should >> > somehow the pager >> > >> thread get woken up without work to do. >> > >> >> > >> Index: DatabasePager.cpp >> > >> =================================================================== >> > >> --- DatabasePager.cpp (revision 8398) >> > >> +++ DatabasePager.cpp (working copy) >> > >> @@ -273,6 +273,7 @@ >> > >> databaseRequest = _requestList.front(); >> > >> _requestList.erase(_requestList.begin()); >> > >> } >> > >> + updateBlock(); >> > >> } >> > >> >> > >> >> > >> I am not sure if I need an osg-submissions mail for this? >> > >> >> > >> -- >> > >> Cheers, >> > >> Csaba/Jester.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> >> > >> >> > >> The information contained in this communication may be >> > CONFIDENTIAL >> > >> and is intended only for the use of the recipient(s) named >> > above. If >> > >> you are not the intended recipient, you are hereby >> > notified that any >> > >> dissemination, distribution, or copying of this >> > communication, or any >> > >> of its contents, is strictly prohibited. If you have >> > received this >> > >> communication in error, please notify the sender and >> > delete/destroy >> > >> the original message and any copy of it from your computer >> > or paper files. >> > >> _______________________________________________ >> > >> osg-users mailing list >> > >> osg-users@lists.openscenegraph.org >> > >> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph >> > >> .org >> > > >> > > >> > > >> > > -- >> > > Serge Lages >> > > http://www.tharsis-software.com >> > > _______________________________________________ >> > > osg-users mailing list >> > > osg-users@lists.openscenegraph.org >> > > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> > > org >> > > >> > > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce >> negraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> > >> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/disclaimer/email.html >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > > -- > Serge Lages > http://www.tharsis-software.com > -- Serge Lages http://www.tharsis-software.com
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
