[PyKDE] Singleshot problems in QThreads on Windows.

[David Boddie]

Sorry not to have joined this discussion before. It's quite a surprise that
I might have something worthwhile to say about threading!

On 20 Aug 2004 17:32:21, "Truls A. Tangstad" wrote:

> On Fri, Aug 20, 2004 at 04:23:09PM +0100, Toby Dickenson wrote:

> > My workaround seems to be working well for us, with non-QThread worker
> > threads:
> > http://mats.imk.fraunhofer.de/pipermail/pykde/2004-August/008364.html
>
> As I mentioned, we did something similar, using Queue, but with
> QTimer.singleShot instead of postEvent, which then makes the
> GUI-thread read from the queue. Problem was now that postEvent might
> be the source of some hangs and QTimer.singleShot isn't working from
> other threads in windows.

Reading the "Thread Support in Qt" document

    http://doc.trolltech.com/3.3/threads.html

I would have thought that connecting QTimers from a non-GUI thread to
slots in the GUI thread probably won't work in quite a few cases:

| Threads and Signals and Slots
|
| The Signals and Slots mechanism can be used in separate threads, as long as
| the rules for QObject based classes are followed. The Signals and Slots
| mechanism is synchronous: when a signal is emitted, all slots are called
| immediately. The slots are executed in the thread context that emitted the
| signal. 
|
| Warning: Slots that generate window system events or use window system
| functions must not be connected to a signal that is emitted from a thread
| that is not the GUI thread. See the Qt Library Mutex section above for more
| details.

QTimer inherits from QObject, so you may well find that you can't use it
in your solution, especially if your slot in the GUI thread is doing the
sort of things mentioned in that last paragraph.

> I'm currently testing an implementation where our own eventsystem uses
> a QTimer created in the GUI-thread to poll every 100 ms for events
> added to the thread-safe queue. If this works we might atleast get a
> new version of our software released over the weekend before isolating
> the problems with postEvent.

I did something like this with qpython (see the PyQt Wiki for a link).
Unfortunately, it's a really wasteful way to wait for events, but it might
be necessary if you choose to use Python threads rather than QThreads.

My current solution is to post events from the non-GUI QThread, but not
include any data with them. The data is stored separately in a Python
object. I think that the interpreter can access the attributes of
pure-Python objects from any thread, and this appears to work well, but
you may be experiencing issues that prevent you from using this approach.

The code for qpython-0.55 should get uploaded today. It's not very pretty,
but I hope that you get something worthwhile out of it!

Good luck!

David