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

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

if that's the case, then why write ANYTHING threaded. its not worthwhile to 
consider the thread saftety of ever single system, libc call libstdc++ unless 
the developer is absolutely sure that its going to cause problems. for 
example, who really cares if the environment isn't protected. how many 
applications actually write to the environment table, and how many more have 
a requirement that multiple threads access it.

the goal in providing threading support is to make it available to 
applications that WANT to use it. simply linking against a threaded library 
isn't going to cause a thread unaware application to crash or even cause 
issues related to it.

so, once threading is available, later versions of various applications may 
decide that a threaded architecture is the way to go. then, and only then, 
the responsibility lies with the developers to sift thru their code, 
identifying places that nead read/write protection.

> Otherwise, if kde goes the thread-only route, it probably won't be stable
> on anything but Linux, and maybe not even on Linux...

not at all true. qt provides minimal thread and synchronization support for 
multiple platforms. i'm willing to believe that a portable application using 
QThread will run exactly the same on windows, linux and solaris. yes there 
are some discrepencies in the way they work, but so far Qt has done a good 
job of only supporting the least common denominator to support maximum 
portability (for example, QThread has no cancel() method which is supported 
by pthread and thread but not win32. it also has no suspend() or resume() 
which are available in win32 but only some versions of pthread).

i understand your concerns, but realistically "thread safe" is a per instance 
quality of code and doesn't require massive rewrites, redesigns or 
re-architecture to solve these problems.

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]