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

List:       kde-devel
Subject:    Re: threading in kde
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-09-07 3:20:08
[Download RAW message or body]

#if Andrew Sutton
> KMutex - standard mutex 
> KCondition - condition variable 
> KSemaphore - semaphore (not tested)
> KThread - your basic thread abstraction

The above 4 are all provided by Qt and we should be able to rely on them
working cross-platform and being maintained - is there a reason you want
to replace them, or are they merely extensions (subclasses) of the Qt
equivalents ?

> KThreadManager - a class that can manage threads globally or per instance.
> 
> basically, the thread class supports all the flags that pthread_create 
> supports although it hasn't been tested. in order to implement a thread, you 
> have to derive from KThread and overload KThread::run(). not very complicated.
> 
> The thread manager is a nice piece of work (IMHO). it's a management point 
> for threads. there's a single global thread manager (accessible via 
> KThreadManager::instance()). a KThread can migrate between managers using 
> KThread::setManager(). a manager lets you wait on all the threads it manages, 
> cancel them and send them signals (using pthread_kill()).

That sounds quite useful.

> also, there's a group abstraction that allows a KThreadManager to work with 
> groups of threads, allowing the manager to, say, wait for one group to finish 
> while another group does its thing. its useful if you have a lot of threads 
> in your system. Threads can also be moved between groups using 
> KThread::setGroup().

> here's the todo list:
> 
> KBarrier - synchronization object that can be used to have several threads 
> reach a certain state or point (barrier) before proceeding.
> KThreadKey<T> - typesafe thread local storage key
> KThreadPool - Some kind of thread pool
> 
> and then the active object stuff...
> 
> KMessageBlock - A thread share message that
> KMessageQueue - A queue specifically designed for the message block complete 
> with a blocking get()
> KTask - A special KThread with a message queue for asynchronous messaging
> KMethod - An abstrace class used to implement asynchronous method invocation 
> can be used with KMessage block to implement asynchronous method invocation
> KResult<T> - A typesafe return class for asynchronous methods

These also sound useful, though I'd like to know how you deal with
the situation where people pass implicit shared (MT-unsafe) Qt
classes (e.g. QString) through objects of these classes. 

Rik

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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