[ThreadWeaver] Several Weaver instances
Paulo Moura Guedes
moura at kdewebdev.org
Thu Apr 19 10:42:30 BST 2007
On Thursday 19 April 2007 09:00, you wrote:
> > Anyway I got this job that should only be started when all jobs of a
> > certain kind are finished. I couldn't find a way to do this, as
> > addDependency() works with instances of jobs, not job types.
>
> This sounds to me like you want to put all the other jobs into on
> collection, set up a dependency between the collection and the cleanup job,
> and queue both.
Perfect :)
> If this is a generic "do this when everything else is done", priorities are
> the way to go. But there are few solutions where this makes sense.
It is now, by coincidence. The previous solution is great and fits all my
needs.
> Generally, I would avoid trying to manage multiple queues. Instead, one
> queue with many threads and a well-thought-of set of dependencies and
> resource restrictions leads to better performance and a cleaner
> implementation. It is like the processors in your computer - you do not
> want to care which one does what, you just tell the OS how you want done.
Several queues makes sense in KLinkStatus because the user can open several
tabs each one of them checking broken links. If the user only has one session
open there will be one queue only. If there are several sessions, it's like
several application instances running, but in this case using tabs. Otherwise
(using only one queue), I would have to keep track of each job to know to
which session it belongs to...
> If multiple jobs are related in a bigger picture, it is advisable to
> inherit JobCollection (or JobSequence) and put them all in there, then you
> have a nice unit of execution.
Well, do you think it's preferable to have one collection for each session,
instead of one seperate weaver queue, and then children collections?
It doesn't seem so clean to me, as I would have to keep a reference to the
main collection in each session, and would receive job done events for other
sessions.
Paulo
More information about the kde-core-devel
mailing list