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

List:       kde-devel
Subject:    Re: threading in kde
From:       Marc Espie <espie () quatramaran ! ens ! fr>
Date:       2001-09-07 16:36:43
[Download RAW message or body]

In article <0GJ8002H9IGMJQ@mail.uni-bielefeld.de> you write:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thursday 06 September 2001 00:19, Andrew Sutton wrote: 
><snip> 
>> 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. 
>> 
><snip> 
>> 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 
><snip> 
> 
>The problem here is that neither Qt, nor kdelibs, nor any other KDE
>program is currently thread-safe. Qt uses a global library lock for
>everything but the tools classes and in kdelibs there are zillions of
>static objects (e.g. factories), none of which is protected against
>concurrent access. 

In fact, if you look at the POSIX threads model, you'll notice that most
system/lib calls are not thread-safe. For instance, getenv() is not 
thread-safe.

Of course, there are libraries like the glibc which go quite beyond the
minimal requirements. But you can't count on having these. You also can't
count on having a thread-safe libstdc++.

In reality, there's even a large cost to thread-safety that many applications
are unwilling to pay.

Are you ready to read through kde's code to ensure all functions you call
are guaranteed thread-safe ?

Otherwise, if kde goes the thread-only route, it probably won't be stable
on anything but Linux, and maybe not even on Linux...
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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