[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-07 4:48:24
[Download RAW message or body]

On Thursday 06 September 2001 22:20, Rik Hemsley wrote:
> #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 ?

decisions... i decided not to use qt at all in my implementation - it frees 
me up from having to deal with the bulk of qt for such a small library. oh - 
and qt's thread stuff doesn't seem to be cross platform, as i've not seen any 
qthread_win.cpp in anything i've gotten from their site, but i might have 
just overlooked it.

deriving kthread from qt thread wouldn't gain any significant advantage for 
my implementation or for kde services that don't require qt to run. its also 
become increasingly obvious to me that alot of qt apps could be written using 
a non-qt threading model.

the model that i prefer for guis is to have the gui run in one thread (say 
the main thread) and to have various threads performing non-gui related 
tasks. the gui can communicate with those tasks thru asyn messaging or method 
invocation (if needed).

of course, since qt has threading support, i'm going to try to port all my 
work straight into the qt library and see if trolltech won't integrate it 
into qt. hopefully, get the best of both worlds :)

> That sounds quite useful.

thank the ACE group. i'm taking that concept from them.

> 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.

that's a tough one... its tough to make thread unsafe code thread safe. 
probably the best thing that could be done would be to write a template 
wrapper that allows a lock to be externally applied to the shared class. 
something like:

template< class T >
class SharedResource
{
protected:
	T *object;		// the mt-unsafe shared object
	KMutex mutex;		// QMutex? locking mutex

	SharedResource( T *obj ) { object = obj; }
	~SharedResource() { /* don't delete anything */ }

	operator T *() { return object; };
	operator T &() { return *object; };

	void lock() { mutex.lock(); }
	void unlock() { mutex.unlock(); }
};

that would probably work. thoughts?

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]