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

List:       kde-devel
Subject:    Re: Multithreaded application development
From:       Christian Gebauer <gebauer () bigfoot ! com>
Date:       2001-06-17 11:05:16
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Saturday 16 June 2001 10:05 pm, Cristian Tibirna wrote:
> > On Sunday 17 June 2001 00:18, Waldo Bastian wrote:
> > > On Saturday 16 June 2001 07:22 pm, Jeff brubaker wrote:
> > > >   Does this mean that no applications included in the base distribution
> > > > of KDE use threads at all?
> > >
> > > I believe arts uses threads. But arts doesn't depend on KDE. I don't
> > > think any actual KDE application uses threads, but I'm not 100% sure.
> >
> > knode?
> 
> Aren't you mixing up msg-threads and "pthreads" now?

No, Cristian is right, both knode and kdict use pthreads for
asynchronous network access and data processing. Their design has
historical reasons - this code was written in pre-KDE2 times.

I plan to port both programs to kio in the near future. This
will obsolete pthreads for kdict, but its possible that we keep
a thread in knode for data processing. We will see...

Anyway, knode is a nice example of what is possible in KDE wrt
multithreading without using the QThread framework:

* the network threads are strictly non-gui (even kdDebug() is forbidden)
* in the gui thread we have monitor class which is connected to the
  network threads via pipes (QSocketNotifier...).
* the monitor class has a queue of pending jobs. When the network thread
  is idle, it transfers the data for the first job to the thread and
  sends a signal to the thread. The thread processes the job and 
  notifies the monitor class when it is done, or it wants to print
  a progress message, etc. The monitor job extracts the data of the
  processed job and forwards it to the right GUI class.

Greetings
Christian
-- 
>><< Christian Gebauer >><< gebauer@bigfoot.com >><< ICQ 14916141 >><<
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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