[PATCH] Fix ThreadWeaver JobCollection deletion race

[Robert Knight]

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