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 - <[EMAIL PROTECTED] e r o c a m p.org> _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
