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

List:       kde-devel
Subject:    Re: threading in kde
From:       Andrew Sutton <ansutton () sep ! com>
Date:       2001-09-05 22:19:26
[Download RAW message or body]

On Saturday 01 September 2001 14:58, Rik Hemsley wrote:
> #if Andrew Sutton
>
> > > I'll be happy to help if you need any questions answered.
> >
> > cool, thanks :)
> >
> > quick question - to start with. i imagine a solid threading library is
> > something that could be useful to numerous applications. exactly how
> > portable should this code be? or at least what platforms do you think it
> > should build on?
>
> I wouldn't worry about win32 stuff right now :)

i didn't :)

if anybody's interested, i have the beginning of what i hope to be a pretty 
comprehensive threading library. its based on the ACE toolkit, so i hope to 
get most of the threading concepts from there. i'm just not sure what to do 
with it now :)

here's a list of things i've written:

KMutex - standard mutex 
KCondition - condition variable 
KSemaphore - semaphore (not tested)
KThread - your basic thread abstraction
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()).

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 bad things:
	- there's no build environment (doesn't use autoconf)
	- not ported
	- not fully tested.
	- i still don't know what to do with it.

if somebody wants to help, i'd be interested in putting it out there for 
general consumption and edits - say on SF.

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

can anybody think of other things they'd like to see?

Andrew Sutton
ansutton@sep.com
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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