Den 23-10-2012 06:50, d3fault skrev:
> OT'ish (relative to above): someone mentioned in reply to me that
> implementing QThread's run() method is needed for the pure computation
> use case. This is simply not true, please stop spreading misinformation.
Now I'm getting annoyed. You're the one spr
re: this whole thread
I'm not sure it's fact, but what I've come to... err... believe... is that
while yes, Qt does provide low level primitives for synchronizing threads,
you should not have to use them! Basically if you think you do, you should
instead change your application's design (for those
Am 22.10.2012 um 16:07 schrieb Jan Kundrát :
> On 10/22/12 14:12, Till Oliver Knoll wrote:
>> So the net effect is that the "worker thread" does "one loop too much"
>> - but /eventually/ it will see that m_continue has been set to 'false'
>> and will terminate. And that is exactly what we want and
On segunda-feira, 22 de outubro de 2012 15.18.17, Thomas McGuire wrote:
> Therefore, if your two threads are living on different CPUs, one CPU might
> not see the update on the other CPU, since the CPU caches are not updated.
> volatile does not help with that, you need proper memory barriers.
I
Den 22-10-2012 15:51, Jan Kundrát skrev:
> On 10/22/12 14:16, Bo Thorsen wrote:
>> Not correct. Neither the compiler nor the CPU can reorder around a volatile.
> Hi Bo,
> various sources which I've read about this topic (like [1], [2], [3],
> [4]) disagree. I might be wrong and would like to be cor
On 10/22/12 14:12, Till Oliver Knoll wrote:
> So the net effect is that the "worker thread" does "one loop too much"
> - but /eventually/ it will see that m_continue has been set to 'false'
> and will terminate. And that is exactly what we want and hence "good
> enough" (no need for protecting the
On 10/22/12 14:16, Bo Thorsen wrote:
> Not correct. Neither the compiler nor the CPU can reorder around a volatile.
Hi Bo,
various sources which I've read about this topic (like [1], [2], [3],
[4]) disagree. I might be wrong and would like to be corrected in that
case -- references are welcome.
Hi,
On Monday 22 October 2012 14:16:33 Bo Thorsen wrote:
> Den 22-10-2012 12:10, Jan Kundrát skrev:
> > On 10/22/12 07:21, d3fault wrote:
> > According to my understanding, the reason for this is the C++ memory
> > model (or lack thereof); while volatile might look like a great way to
> > force a
On 10/22/2012 10:57 AM, Bo Thorsen
wrote:
Den 22-10-2012 03:38, Syam Krishnan
skrev:
A question to all:
I have a GUI application. I need to do some task (for example,
periodically readin
Hi Daniel,
No matter what you do, you have an object living between threads. If you
use AOD, then that object is the one with this "problem". Something
needs to sit between the threads. That might not be the case in boost,
but in Qt there is no way around this. You need an object to hold the
Den 22-10-2012 12:10, Jan Kundrát skrev:
> On 10/22/12 07:21, d3fault wrote:
>> volatile bools work
> I wasn't able to find a context for this, but in general, this is not
> true.
In general, no. For all x86 and x86-64 processors, it is true. Ints and
bools have atomic reads and writes on th
2012/10/22 Jan Kundrát :
> On 10/22/12 07:21, d3fault wrote:
>> volatile bools work
>
> I wasn't able to find a context for this, but in general, this is not
> true. Declaring a variable volatile does *not* make it suitable to be
> used as a synchronization primitive across threads.
In Academi
>Could you elaborate? One of the reasons I prefer QThread is that the
>SIGNAL/SLOT provides a thread-safe signalling/communication bridge across
>threads.
There is that. I've not had a case in my own code however where I needed that.
I use invokables (std::function or boost::function) for cal
Hi,
I am having an issue with Z-Fighting when I put my Qt-Application, which
has no frame and is transparent, ontop of an simple OpenGl Application
(triangle example).
Does anybody know how to fix this issue?
The only thing I found is to use following line to make the used OpenGL
variables invari
Daniel spaketh:
> You should look into the active object design pattern. The idea is that you
> hide the object that lives in another thread behind a managing object. I
> only discovered this recently and it’s vastly superior to subclassing
> QThread, or using moveToThread or any of that rubbish.
The problem with the subclassing pattern is that you end up with an object
spanning two threads. You class is instantiated in the main thread (along with
it's member data) but run(), when called, is operating in a different thread.
It's all too easy to get into a mess doing this.
You should loo
On 10/22/12 07:21, d3fault wrote:
> volatile bools work
I wasn't able to find a context for this, but in general, this is not
true. Declaring a variable volatile does *not* make it suitable to be
used as a synchronization primitive across threads. As a side effect, it
might also make the co
Hi All,
the tooltip doesn't work on Windows Vista in 4.8.3, probably because of bug
https://bugreports.qt-project.org/browse/QTBUG-18821
Is there a workaround or something if I want to use the tooltip?
Stanislav Kolar
Research & Development
.
Hello,
I've an application which runs nicely on linux (Qt 4.7.3 gcc 4.1.2 32 bits)
and I want it to run on windows XP 32 bits. So I've been built it inside
eclipse (not my choice, it is part of a bigger C++ project), everything was
fine until I want to execute it. It crashed poorly giving me the f
19 matches
Mail list logo
