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

List:       kde-devel
Subject:    Re: Ark restructuring - is separate thread handling possible?
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2008-09-10 22:23:57
Message-ID: 200809110023.58231.aacid () kde ! org
[Download RAW message or body]

A Dimecres 10 Setembre 2008, Harald Hvaal va escriure:
> Hello
>
> Lately I've been kind of annoyed at the internal structure of Ark and
> wanting to improve it, and just thought of a possible solution that I would
> like some comments on here. First a few words on the internal structure.
>
> Ark has classes for adding, deleting, extracting and listing, respectively
> AddJob, DeleteJob, ExtractJob and ListJob, all inheriting from KJob. For
> threading support, there is also another set of classes, respectively
> called InternalAddjob, InternalDeleteJob etc, inheriting from
> ThreadWeaver::Job.
>
> Now, one thing I definitely want to do is move a lot of duplicate code from
> the outside Job classes into a common parent class. The other thing that I
> noticed is, why does there have to be a whole set of duplicate InternalJob
> classes at all? To have this thread functionality, how about if I do:
> - in the Job class, implement the actual workload in a separate function
> doWork().
> - the run method in the Job class (KJob, does not actuallly thread) spawns
> a generic threadweaver job that then calls this doWork() workload function
> from a new thread
> - when this job is finished it returns the results and notifies the
> original job.
>
> The way I see it this would move all threading code into a single generic
> class, and have the workload and interface to the jobs defined in the
> original Job classes.

Having a quick look at KJob i don't see why it should not work, but i'm not a 
KJob expert either :D

Albert

>
> Is there some kind of a technical restriction that would not allow me to do
> this? Is there actually a reason why the original developer chose this
> first KJob, then ThreadWeaver Job structure?
> (As a sidenote, I do know that in early phases it was all ThreadWeaver
> classes, and then encapsulated into KJobs, so the reason might very well be
> laziness)
>
> Harald Hvaal
> haraldhv@stud.ntnu.no
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]