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

List:       kde-core-devel
Subject:    Re: threads
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       1999-12-04 21:22:16
[Download RAW message or body]



Jo Dillon wrote:
> 
> Waldo Bastian (bastian@suse.de) spake thusly:
> > I guess that the Troll's don't want to make Qt dependant on threads, so for
> > this to work, QApplication should call a virtual function whenever it is about
> > to call select and call another virtual function after select has returned.
> 
>   Well, we at Trolltech hacked something last night that might be useful
> here (yes, I know I'm using the wrong email address ;) What we actually
> hacked was a thread-safe event posting mechanism, but QApplication
> now emits a signal guiThreadAwake() at the start of processNextEvent
> (where the select call is made). there's also a member function
> wakeUpGuiThread which will cause the next select() to time out immediately

This sounds very simmilar to the Swing idiom of calling invokeLater().
It works pretty well in a lot of cases, but it would still suffer from
the problem of non-thread safe iterators I think.

Rich.

> (we needed this for the event posting). We've also introduced
> QMutex and QThread classes, but there's no guarantee these will be in
> a Qt release soon, and the QThread API in particular is rather likely
> to change (it was added mainly in order to write a platform-independent
> test application ;)
>   Perhaps some or all of this code could be useful in KDE if people want
> to use threads?
> 
> --
> 
>         Jo

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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