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

List:       kde-devel
Subject:    Re: KDE & Multithreading
From:       Charles Samuels <charles () kde ! org>
Date:       2002-02-09 0:43:46
[Download RAW message or body]

On fredag 08 februar 2002, 01:21 pm, Jay Cornwall wrote:
> Hi
>
> I'm writing a multithreaded KDE application at the moment, which needs to
> be able to access the GUI (changing the status bar, lighting an LED, etc.)
> from different threads. The general impression I'm getting, from segfaults
> and from reading on the net, is that this isn't really feasible. QT's
> libqt-mt helps a little, but some things still can't be done without
> compiling KDE with multithreading suport (KDialog's, for example).
>
> I used to write multithreaded apps for my old Amiga, using MUI (Magic User
> Interface), an OO GUI toolkit. This also didn't support accessing a GUI
> from multiple threads, but solved the problem by providing a method to
> "stack" GUI changes from any thread, which would be executed by the main
> thread shortly after.
>
> However, KDE's use of QApplication::exec() seems quite restrictive,
> effectively blocking the main thread from doing anything along these lines.
> It makes me wonder how multithreaded KDE applications are implemented?
>
> I agree that having all GUI accesses in one thread is a much better
> solution, but my program needs a separate thread for network access, or it
> slow the GUI to a crawl.

Well, your question isn't very specific, so my answer of sort will be very 
general.

So, I assume you're using the posix network calls (and not the Qt ones), since 
the Qt ones are all non-blocking, and require an event loop to select() the 
file descriptor. (btw, QSocketDevice doesn't need an event loop).  Anything 
that needs an event loop needs to be in the main thread.

You can have your second (network) thread send messages to the main thread 
(e.g., progress info) via QThread::postEvent.

Ideally, you should be using KIO to get data, but I'm aware that it's not 
great in all cases.

Instead of postEvent, you can also use ITC (www.derkarl.org/itc), which was 
written by me.  it is much faster than postEvent, and is especially nice for 
cases where you have an interface on a second thread.  But I only say this 
because I love "advertising" ITC ;)

-Charles

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]