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

List:       kde-devel
Subject:    RE: QMap bug ? (Re: kioslaves don't die?)
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-11-11 13:06:29
[Download RAW message or body]

On Thu, 11 Nov 1999, Alexander Feigl wrote:
> At Don, 11 Nov 1999 David Faure wrote:
> > > Hi
> > > 
> > > ok, now we know we have to fix it - if QMultiMap is not here in the near
> > > future. But we better don't count on that. Should we do the change to
> > > QMap/QList?
> > 
> > Yes, looks like.
> > Can you have a go at it ?
> 
> Hmm. Only if it doesn't really hurry. I cannot promise whether I can do it this
> evening. And from Friday until Monday I'm not at home - I would have the time
> but I don't have a laptop :(

Shall I have a look at it?
 
> Two issues:
> 
> - kdelibs is feature-frozen - isn't it? Does it matter that the change would
> affect binary compatibility of KIOSlavePool? Looks like a rather internal
> class. Does it affect binary compatibility at all if we change/add static class
> members?

Binary compatibility is not so important at the moment. Just make sure
that any code using KIOSlavePool still compiles (e.g. either stay
source compatible or adapt the code that depends on it as well.)
 
> - we need a "total slave count" to delete the oldest slaves if the number of
> slaves becomes to large. Any "smarter" but also efficient solutions than
> keeping a static int as counter? Also I cannot see how the slaves are actually
> terminated by calling remove() on the QMap object.. Is this another bug?

Cheers,
Waldo

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