[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-08-30 7:25:09
[Download RAW message or body]

#if Andrew Sutton
> just curious, but what kind of threading support does kde have? i've seen 
> what qt has but i'm not very impressed.

KDE has 0 thread support today. Tomorrow we switch to using Qt 3 in
CVS' HEAD branch, and will henceforth be able to use QThread.

Qt's thread support is held back by two things currently:

* It has to work on many platforms
* Many of the 'tool' classes are copy-on-write with no MT protection.

> actually, another question -- or at least note. i'm surprised that there 
> doesn't seem to be any real threading support at the kde level. is there any 
> particular reason (other than dependency on qt?)

Before KDE 2 was released, we decided not to use the MT Qt. This was
because Qt had only just acquired MT support, and we didn't have time
to thoroughly test KDE using the MT version of the library.

We couldn't switch to the MT version until now, unless we wanted to
break binary compatibility on non-Linux platforms.

Having said this, KDE itself manages pretty well without thread support.

* The KIO library provides us with non-blocking I/O - with other added
  benefits, such as the fact that kioslaves can be controlled as groups,
  shared between processes, and don't crash the owning application if
  they die unexpectedly.

* The event-based model provided by Qt allows for simulating 'background
  processing' in a fairly natural fashion.

Klass::Klass()
{
  startTimer(100);
}

Klass::timerEvent(QTimerEvent *)
{
  doSomeProcessing();
}

Some might call that 'co-operative multitasking' ;)

Ok, using the event loop + timers isn't as elegant as using threads,
but it's simple, easy to understand, and quite easy to implement
without starting to worry that you've got some nasty locking problem
lurking deep in the system.

Of course, as KDE becomes larger and more complex, more elegant
solutions become more desirable.

> the reason i ask, is because i read somewhere that KDE3 would offer a little 
> more in the way of threading. my current work project has me working with 
> this wonderful little (yea right) package called ACE (Adaptive Communications 
> Environment) that provides some very nice pattern oriented OO software for 
> threading, communications and pretty much everything except the gui.

ACE is great, but does it provide anything we desperately need ?

The KIO model handles our comms quite well. We can now use QThread for
CPU-intensive operations when we want to avoid blocking the UI...

Can you think of any concrete examples that show why we would want to
use ACE ? I haven't looked at it for long enough to see where it might
be useful for us, so I'm genuinely interested to hear if you have
suggestions.

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]