[PyKDE] Singleshot problems in QThreads on Windows.

[Truls A. Tangstad]

On Sun, Aug 22, 2004 at 04:34:09PM +0200, David Boddie wrote:
> 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:
> 

<snippet from Qt-documetation>

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

You are correct, the Qt documentation clearly states:

| Any operations that generate events must not be called by any thread
| other than the GUI thread. Examples of such operations are:
| 
| * creating a QWidget, QTimer, QSocketNotifier, QSocket or other
|   network class.

and later:

| Events generated by these operations will be lost on some platforms.

So it seems that the QTimer approach causes undefined behavior which
happened to work on Linux atleast.

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

What kind of events are you posting?

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

I could not find any link or reference to it on the PyQt Wiki though.

> Good luck!

Thanks! Our current poll based implementation is working, but we'd
really like to go back to using postEvent with data if we can get that
working.

-- 
Truls A. Tangstad - <kerfue+pykde at h e r o c a m p.org>