[PATCH] Fix ThreadWeaver JobCollection deletion race

[Robert Knight]

> I just been committing the patch attached in the original email which

That should be "just mean committing".

On Thu, 2008-03-27 at 23:03 +0000, Robert Knight wrote:
> Hi Matt,
> 
> I just been committing the patch attached in the original email which
> ensures that JobCollection jobs do not emit their done() signal until
> the jobs in the collection have emitted their done() signal.
> 
> Using shared pointers for jobs is a separate issue and assuming binary
> compatibility is to be maintained, ThreadWeaver::Job cannot have a new
> base class added, although a proxy class could be created if necessary.
> 
> Regards,
> Robert.
> 
> On Thu, 2008-03-27 at 14:16 -0500, Matt Rogers wrote:
> > On Thu, Mar 27, 2008 at 10:17 AM, Robert Knight <robertknight at gmail.com> wrote:
> > > Hi,
> > >
> > >
> > >  > Wouldn't the perfect solution here be using shared-pointers(KSharedPtr) for
> > >  > jobs?
> > >
> > >  Yes, I think so.  Job itself is part of threadweaver though and adding a
> > >  new base class (QSharedData) would be BIC.  This could be done just for KDevelop::ParseJob though,
> > >  on the assumption that any child jobs would have the ParseJob as their parent and be deleted at the
> > >  same time.
> > >
> > >  No objections on kde-core-devel or here so I'll commit the fixes to ThreadWeaver itself.
> > >
> > >  Regards,
> > >  Robert.
> > >
> > >
> > >
> > >  On Thu, 2008-03-27 at 15:06 +0100, David Nolden wrote:
> > >  > On Wednesday 26 March 2008 22:38:23 Andreas Pakulat wrote:
> > >  > > IMHO its a really bad idea to expose the jobs pointer via public api and
> > >  > > advertise usage of the pointer in slots and at the same time delete the
> > >  > > job object behind the back of the slot-users.
> > >  > >
> > >  > > So maybe we should just add this possibility to parse jobs as well, that
> > >  > > way if somebody queues a parse job he can also make sure he deletes the
> > >  > > parse job himself if he expects need for the parse-job data after the
> > >  > > job finished. Thats what I did for KJob to be able to use the jobs after
> > >  > > the work has been done (in the vcs support).
> > >  > >
> > >  > > Andreas
> > >  >
> > >  > Wouldn't the perfect solution here be using shared-pointers(KSharedPtr) for
> > >  > jobs?
> > >  >
> > >  > The job would be automatically deleted exactly when it isn't needed any
> > >  > more(This also works with queued connections, as long as the job is given as
> > >  > KSharedPtr<Job>).
> > >  >
> > >  > Greetings, David
> > >  >
> > >  > _______________________________________________
> > >  > KDevelop-devel mailing list
> > >  > KDevelop-devel at kdevelop.org
> > >  > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> > 
> > I don't understand what you mean when you say "you'll make the changes
> > to Threadweaver itself". Does this mean you're giving
> > Threadweaver::Job a new base class of QSharedData? or are you doing
> > something different?
> > 
> > _______________________________________________
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>