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

List:       kde-devel
Subject:    Ark restructuring - is separate thread handling possible?
From:       Harald Hvaal <haraldhv () stud ! ntnu ! no>
Date:       2008-09-10 9:14:20
Message-ID: 200809101814.20767.haraldhv () stud ! ntnu ! no
[Download RAW message or body]

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.

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 <<
[prev in list] [next in list] [prev in thread] [next in thread]