Adding ThreadWeaver libraries to kdelibs

[Simon Hausmann]

On Tuesday 5. September 2006 21:35, Mirko Boehm wrote:
> Hi folks,
>
> I think ThreadWeaver is ready for prime time. If you haven't followed it:
> ThreadWeaver is a job queue that had advanced capabilities for automatic
> scheduling of application operations. As far as I know, kdevelop, koffice
> and kdepim are using it or plan to use it as soon as it is commonly
> available.
>
> ThreadWeaver is developed in kdenonbeta at the moment, and usually snapshot
> and point-released when it reaches a certain new useful state. It is
> tested, known to be stable, and comes with a set of unit tests.
>
> I would like to suggest to add the two main libraries - the Weaver library
> that contains the job queue and surrounding classes, and the WeaverGui
> library that holds everything that depends on QtGui, and the accompanying
> unit tests, into kdelibs. I guess it will be best to import the snapshot
> point releases into kdelibs, to maintain a state where everything works and
> is tested, and update as needed. I will take care of the updating.
>
> As for the rest, I would like to move it to kdesdk. Unstable versions
> should be kept and tagged and merged as needed.
>
> Please let me know what you think about it.

Looks great! A few minor API suggestions though:

JobCollection::jobListLength() -> jobCount(). Count is the common term used in 
Qt for numbering independent objects in a container. It also goes nicely with 
jobAt(i). Length on the other hand is used for things like QLineF::length.

It looks like some functions lack const: JobCollection::canBeExecuted(), 
*Policy::canRun(), hasUnresolvedDependencies().

ResourceRestrictionPolicy::cap: Lacks a getter, and I suggest a different 
name. Perhaps jobLimit or maximumJobCount. (compare leo:cap with leo:limit :)

Weaver{Interface}: I suggest to replace *NumberOfThreads with simply 
maximumThreadCount(), threadCount().

For the simplicty of the API (less classes) I also suggest to merge 
WeaverObserver with WeaverInterface, since WeaverObserver does not provide 
any functionality but just signals.

Also with WeaverThreadGrid I suggest to put all member variables into a 
d-pointer.

Job has isFinished() but also bool success(), which looks a bit ugly IMHO. 
Maybe it would be simpler to have a non-virtual exitStatus()/setExitStatus() 
property instead of the virtual success function. That's more extensible 
(with an enum instead of a virtual function that cannot be changed later) and 
it reads nicely:

if (job->isFinished() && job->exitStatus() == Job::ExitSuccess)

And perhaps isFinished() should just be called finished(). That's used more 
often in Qt these days than isFinished().

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060906/e8fdfce0/attachment.sig>