[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: extragear/sdk/kdevelop/app
From:       David Nolden <zwabel () googlemail ! com>
Date:       2010-04-18 18:41:38
Message-ID: m2r6453d25e1004181141le0c3d9e3ga755f7baabc69f82 () mail ! gmail ! com
[Download RAW message or body]

2010/4/18 Andreas Pakulat <apaku@gmx.de>:
> On 18.04.10 11:29:31, David Nolden wrote:
>> The lock within notify only "locks" within the main thread (that's the
>> expression within the parens), and since the lock is recursive, this cannot
>> lead to a deadlock.
>
> Just changed that to not use a global static (yet again). But my
> question was not wether it can or can not, but wether you tested it? The
> other thing is that the lock adds useless code which has 0 benefit over
> the non-lock version unless you start adding code into the background
> thread that uses it. And that must not happen for 4.0.0 (and IMHO also not
> for 4.0.x)
I tested it in the sense that KDevelop still works, yes. But now that
we have it, we might start using it to fix specific bugs. I don't get
why it should be more dangerous than any other way of fixing a bug, as
any change is at first "untested". Then you test it, and if it works,
it's fine.

However, if we only want KDevelop to work with kdelibs 4.4, I guess we
don't need the lock (yet), and can also revert it. Generally, given
all the changes that seem to be going on in kate, I think we should
completely disallow the startup of KDevelop 4.0 together with kdelibs
4.5.X, as I'm pretty sure it will be a sub-par experience. We can tell
the user to update KDevelop, as we may suppoert kdelibs 4.5.x in a
later release. Else we'll get tons of bug-reports because of kdevelop
+ KDE 4.5 bugs.

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]