[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 6:04:15
[Download RAW message or body]

#if Andrew Sutton
> 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.

QThread works on most UNIX, Windows and maybe MacOS too. I suppose
it _should_ work on all platforms that Qt runs on, otherwise there
wouldn't be much point in having 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.

Quite correct. I wrote a web server without using threads - the
Qt model made this quite easy.

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

That seems to be the best way of working. For KDE apps, this would mean
that mainly CPU-intensive operations go into threads, as async I/O
is handled by KIO, so there's no need for threads there.

> > 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: [...]

I've used something similar - wrapping up the Qt classes with a mutex,
but sadly this causes major CPU overhead. I'd like to see Qt use
atomic counters to protect access to copy-on-write data... see
http://www.geoid.clara.net/rik/qt_mt.html if you fancy reading about
that.

Why use atomic counters ?

* Easily portable (few lines of ASM for each platform)
* Low overhead (nothing compared to mutexes)

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]