Sebastian Moors wrote: > Since the patch seems to help ( at least forGrammostola Rosea (btw, he > was the one who created ticket 101) and you) , i suppose the question is > now how we can integrate those changes into trunk without doing much > damage :)
OK, thanks. In the e-mail he said something about "when loading user drum kits" and also "it doesn't happen in debug, only in release" -- which made me think it was a different (but possibly related) bug. So, I was searching for more details. >> The string literal get implicitly converted to a QString. >> This will _always_ call the QString copy constructor. This is >> fixed by making the string literal a static QString. > try_lock() is used just once in our whole sourcecode, so i could live > with Gabriels static solution. This one is a "no-brainer." We're doing this one. :-) >> * try_lock() still sometimes took too long, >> so I killed the QString assignment for the __locker >> variable. > For the moment we can set __locker to a static "audioEngine_process", > since it is not called from anywhere else. But a very ugly hack :-/ __locker is a debugging convenience. When lock() fails or we have a deadlock, it's helpful to know _who_ has the lock. So, statically setting it to "audioEngine_process" would be pointless... might as well just remove __locker before doing that. What about making it a compile-time option? Something like ENABLE_AUDIOENGINE_LOCKER_ID... but disabled by default. Only enabled when you're chasing a deadlock issue. > Hm, this is not easy to solve. Maybe we could turn the whole xmlparser > related messages (mostly warnings that a user don't want to read..) > into INFOLOG messages, which just show up if you want a debug version. > Well this solves not the problem for the debug version. > > Gabriel, do you think it would help if we speed up the logging and use > c-strings as an argument for ERRORLOG etc. ? Nah, I don't think these will help. The problem is with more with the mutex locking than the QStrings. The problem is that we're locking the logging queue while outputting to STDOUT. This defeats the purpose of even having a logging thread. While sending messages to STDOUT, anything in the process() cycle has to _wait_ if they use ERRORLOG() or the like. However, the lock is currently necc. because the log queue is a std::vector<QString>. If the queue changes, it invalidates _all_ iterators... so we can't allow the queue to change. We might be able to remove the lock (or only lock briefly) by using a std::list<QString>. A std::list<> has constant time insertion (whereas std::vector<> may have to reallocate memory for the whole vector) and it does NOT invalidate iterators if the list changes. Another thought is two have two queues: one for adding messages and one for processing messages. Before processing the queue, there would be a very brief lock to _switch_ them. Anyway... before implementing any of these, I just wanted to make sure that we hit the mark. Peace, Gabriel ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
