Changes to CodeCompletionWorker regarding multithreading

[Milian Wolff]

Andreas Pakulat, 18.01.2011:
> On 18.01.11 09:15:14, Esben Mose Hansen wrote:
> > On Tuesday 18 January 2011 01:57:46 David Nolden wrote:
> > > Anyway the whole concept of binary compatibility, even in kdelibs,
> > > seems superseeded to me. The only applications that profit from binary
> > > compatibility are closed-source apps. Yes I understand that the idea
> > > is that KDE becomes an ecosystem for closed- AND open-source apps, but
> > > the reality after 3 years of KDE4 looks very different, and it doesn't
> > > make the slightest sense to hinder the development just to help an
> > > audience which doesn't even exist. For open-source, source
> > > compatibility is completely enough. When the distribution is using a
> > > decent build-system, then it makes absolutely no difference for them
> > > (see opensuse build-service).
> > 
> > Ah, not quite. There are two other cases for ABI-stability.
> > 
> > There are packagers, which *needs* to have the SO-version correspond to a
> > specific ABI. So every time you break ABI, you need to bumb the so
> > number. They also worry that having 5 different apps depend on 5
> > different ABIs for one library will lead to excessive memory usage and
> > odd dependency graphs.
> > 
> > Then there are the library users. They need to be able to say to their
> > downstream which version of your library to grab. And they would much
> > prefer it if this is a version packed by their downstream's
> > distribution. Constantly changing the ABI increases the risk that the
> > version is not there yet/anymore.
> 
> In addition to that, packagers will just stop packaging libraries which
> change ABI on each minor release if the number of apps using it is large
> enough. And large enough actually depends on how many packagers there are
> in the distribution caring for kdev and how big the infrastructure is. Sure
> SUSE has its buildsystem and other projects have internal distributed
> compile farms. But you're wrong that this means ABI doesn't matter to them.

A good example for this is Boost. It's often a nightmare for packagers and 
users. And only (imo) because they don't have any API stability, just source 
compatibility. Anyways, it will take time until we can do better, but right 
now we do the same like them: Only break ABI across 4.x releases.

Anyways, this discussion is obsolete imo, we have to work with the packagers, 
not against them. Hence this small hindrance to keep the ABI during the 
lifetime of a single 4.x release is just fine.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110118/f243adad/attachment.sig>