Bizzare behavior under X (Qt 4.3.0)

[marcel]

Oh, you are more like a consultant?

Could you expand on what it means to "move the thread into its own context?"

It has been said in other threads. Namely here:http://www.qtcentre.org/forum/f-qt-p...-gui-7322.html, starting from post 15.

But here goes again:
You create the worker thread in the GUI thread. No problem so far.
You connect a signal from the GUI thread to a slot from the worker thread.
Here is the problem, since the signal will actually be posted as an event in the thread's event loop.
But actually, since the thread is owned by the GUI thread, the event processing for it will take place in the GUI thread. Therefore the slot will actually be executed in the context of the main thread.

By calling moveToThread from the GUI thread, you guarantee that any events posted in the thread will get executed in the thread's event handler.

Regards

[slcotter]

Student, actually. It's all academic applications so everything I write is in the public domain. If you want to see any part of my code that deals with.... whatever, just say "I'd like to see the parts that do <this>" and I can make it happen.

I could post it all, too, but then you'd all see what an awful amateur I am.

[marcel]

Student, actually. It's all academic applications so everything I write is in the public domain. If you want to see any part of my code that deals with.... whatever, just say "I'd like to see the parts that do <this>" and I can make it happen.

I could post it all, too, but then you'd all see what an awful amateur I am.

No problem. See if it works this way first...
If not, then we can look further, in the rest of the code.

Regards

[slcotter]

I'll be back tomorrow with an update, then.

Thanks very much for your time.

[slcotter]

As a delayed followup:

The suggestion failed, and the program displayed similar behavior even after being moved into its own context. However, I have worked around the problem.

I've rolled back to an older version of linux. (Scientific linux 4.0, based upon some version of Enterprise Red Hat, I believe)

I'm also using older hardware (Athlon XP, versus the 64-bit dual core Athlon whateveritwas on the other system).

The code now appears to work properly. I may revisit this at some point in the future, but for now I have to move forward with other projects... presuming that it continues to function as it has over the last few days.

I can only hope that this info proves useful to someone in a similar situation in the future. It appears that my issue may be unique to the specific platform I was developing on (Fedora Core 6, 64-bit version).

[marcel]

As a delayed followup:

The suggestion failed, and the program displayed similar behavior even after being moved into its own context. However, I have worked around the problem.

I've rolled back to an older version of linux. (Scientific linux 4.0, based upon some version of Enterprise Red Hat, I believe)

I'm also using older hardware (Athlon XP, versus the 64-bit dual core Athlon whateveritwas on the other system).

The code now appears to work properly. I may revisit this at some point in the future, but for now I have to move forward with other projects... presuming that it continues to function as it has over the last few days.

I can only hope that this info proves useful to someone in a similar situation in the future. It appears that my issue may be unique to the specific platform I was developing on (Fedora Core 6, 64-bit version).

Well, this sucks.

Since you noticed that it works ok on a single CPU machine, I assume it is a problem related to concurrency.
On the new machine, the GUI thread and the worker will never be scheduled to run concurrently, while on the dual core CPU there were a lot of chances to run in the same time.

This leads to an assumption about deadlocks and/or memory violations on shared areas.


Unfortunately, I don't have a dual core cpu, otherwise I would have tested your code.
I suggest using Intel thread checker if you ever get the chance to run it on an Intel machine.

Regards