On Wed, 03 Jun 2009 06:07:59 -0500, "Gabriel M. Beddingfield"
<[email protected]> wrote:
>>> * 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.
Sounds good to me.. What about adding a debug-level parameter to "--debug"?
"--debug" would give you just the normal debug output, whereas --debug=all
would give you everything. Or we could pass a list to debug, such as:
"--debug=infolog,lock"
>> 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.
That makes sense ( and should less complex then the 2-queue solution below
).
> 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.
Hm, the comment from hollunder sounds not promising :-/ But at least it
seems to help for #101.
> 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
------------------------------------------------------------------------------
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
