| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Stephen Collyer wrote:
>Iulian M wrote:
>> Out of curiosity why would you ever need a tree-like structure of
>> threads ?
>
>There are several reasons:
You misunderstood the question. We're not asking why you need to have
threads create threads that create sub-threads, etc. We're asking why you
need to have a Parent-Child relationship between QThread objects in the
QObject sense of it.
You can do without that and still accomplish your needs.
>
>1. Practical - I'm porting some code to Qt that already has a
>tree-like structure of processes and that will map most cleanly
>onto a tree-like structure of threads.
You *can* have a tree-like structure of threads. But all QThread objects
have to be created in the same thread (probably your main thread).
The threads can be started from any thread once they are created.
>2. Theoretical - if you can't have a tree-like structure of threads,
>you can only run single threaded code, since a Parent-Child structure
>is already a tree. And if you allow Parent-Child, why should you
>disallow Parent-Child-Child ?
Huh? If you can't have a tree-like structure of threads, you can still use
threads. It will just be a flat list.
>3. Pragmatic - you've got it whether you like it or not, as Qt
>allows it (as do other thread systems)
>
>4. Good design - if you spawn a thread to do a job, good
>engineering practice demands that it be a black box - you
>should neither know nor care if it spawns sub-threads to
>do its job.
Good point.
This being the case, you can do this:
main thread:
thr = new MyThread(QCoreApplication::instance());
thr->start();
MyThread::run()
{
QObject dummy;
thr1 = new SubThread1(&dummy);
thr2 = new SubThread2(&dummy);
thr1->start();
thr2->start();
/* do something to make sure that both threads have finished, like: */
thr1->wait();
thr2->wait();
}
The code above created a three-level tree of QThread-based objects by
dividing it in two trees. The dummy object in MyThread::run() is
allocated on the stack, therefore it lives in that thread.
It has no real QObject parent, but it is technically bound to MyThread's
existence. It will be deleted before MyThread is, which is what the
QObject object tree does for you.
>Finally, it's a common approach anyway - regardless of
>whether we "need" it in any absolute sense, plenty of systems
>spawn threads, and sub-threads, and sub-threads as it's
>such a natural thing to do - note that any Unix box runs a large
>tree of processes. It'd be hard to design a moderately complex
>system if it were disallowed.
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Saturday 01 December 2007, Thiago Macieira wrote:
> Stephen Collyer wrote:
> >Iulian M wrote:
> >> Out of curiosity why would you ever need a tree-like structure of
> >> threads ?
> >
> >There are several reasons:
>
> You misunderstood the question. We're not asking why you need to have
> threads create threads that create sub-threads, etc. We're asking why you
> need to have a Parent-Child relationship between QThread objects in the
> QObject sense of it.
>
> You can do without that and still accomplish your needs.
Actually AFAIK only processes in a system have a parent-child relationship.
Inside a process there is no parent-child relationship between threads. This
does not mean that a thread can't start another thread, it just means that
the first thread does not "own" the second and if the first thread ends ( but
the main thread of the process still runs ) the second will continue to run.
I hope to be corrected if I'm wrong.
>
> >1. Practical - I'm porting some code to Qt that already has a
> >tree-like structure of processes and that will map most cleanly
> >onto a tree-like structure of threads.
>
> You *can* have a tree-like structure of threads. But all QThread objects
> have to be created in the same thread (probably your main thread).
>
> The threads can be started from any thread once they are created.
Processes are different from threads. Mapping a structure of processes to a
structure of threads might be "tricky". Imagine access to static data in
different processes compared to access in different threads.
>
> >2. Theoretical - if you can't have a tree-like structure of threads,
> >you can only run single threaded code, since a Parent-Child structure
> >is already a tree. And if you allow Parent-Child, why should you
> >disallow Parent-Child-Child ?
>
> Huh? If you can't have a tree-like structure of threads, you can still use
> threads. It will just be a flat list.
As i said AFAIK the threads in a process ARE a "flat list". Still you can
start them from different nodes of a tree-like structure of classes.
> >3. Pragmatic - you've got it whether you like it or not, as Qt
> >allows it (as do other thread systems)
> >
> >4. Good design - if you spawn a thread to do a job, good
> >engineering practice demands that it be a black box - you
> >should neither know nor care if it spawns sub-threads to
> >do its job.
>
> Good point.
I agree that it's a good design for a thread to be as a black box. Still a
black box (in general) should have a complete interface containing input
parameters specifications , output param , if it may throw an
exception ...and in practice i would like to know if that black box (the
thread ) is spawning other threads and is possible how many.
If i know my app will run at maximum performance on the target system using X
number of threads and i decide to start X threads and each one of this
threads starts other threads then probably the performance will suffer.
>
> This being the case, you can do this:
>
> main thread:
> thr = new MyThread(QCoreApplication::instance());
> thr->start();
>
> MyThread::run()
> {
> QObject dummy;
> thr1 = new SubThread1(&dummy);
> thr2 = new SubThread2(&dummy);
> thr1->start();
> thr2->start();
>
> /* do something to make sure that both threads have finished, like: */
> thr1->wait();
> thr2->wait();
> }
>
> The code above created a three-level tree of QThread-based objects by
> dividing it in two trees. The dummy object in MyThread::run() is
> allocated on the stack, therefore it lives in that thread.
>
> It has no real QObject parent, but it is technically bound to MyThread's
> existence. It will be deleted before MyThread is, which is what the
> QObject object tree does for you.
>
I do appreciate the parent child relation of QObjects and it's advantages but
this seems like an overuse. Why not just declare the SubThread classes on the
stack ? Am i missing something?
MyThread::run()
{
SubThread1 thr1;
SubThread2 thr2;
thr1.start();
thr2.start();
thr1.wait();
thr2.wait();
}
> >Finally, it's a common approach anyway - regardless of
> >whether we "need" it in any absolute sense, plenty of systems
> >spawn threads, and sub-threads, and sub-threads as it's
> >such a natural thing to do - note that any Unix box runs a large
> >tree of processes. It'd be hard to design a moderately complex
> >system if it were disallowed.
Again processes in a system are different from threads in a process.
http://en.wikipedia.org/wiki/Thread_(computer_science)
I hope I haven't said stupid things :)
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Iulian M wrote:
> On Saturday 01 December 2007, Thiago Macieira wrote:
>> Stephen Collyer wrote:
>>> Iulian M wrote:
>>>> Out of curiosity why would you ever need a tree-like structure of
>>>> threads ?
>>> There are several reasons:
>> You misunderstood the question. We're not asking why you need to have
>> threads create threads that create sub-threads, etc. We're asking why you
>> need to have a Parent-Child relationship between QThread objects in the
>> QObject sense of it.
>>
>> You can do without that and still accomplish your needs.
>
> Actually AFAIK only processes in a system have a parent-child relationship.
> Inside a process there is no parent-child relationship between threads. This
> does not mean that a thread can't start another thread, it just means that
> the first thread does not "own" the second and if the first thread ends ( but
> the main thread of the process still runs ) the second will continue to run.
>
> I hope to be corrected if I'm wrong.
There's no magic parent-child relationship between "processes" that
can't exist between threads. However, the whole question is
system-dependent and relies on your definition of one process or
thread "owning" another. Until the precise terms and concepts are
defined, it's pointless to discuss it further (and waa--aa-aay off
topic for this list).
> Processes are different from threads. Mapping a structure of
processes to a
> structure of threads might be "tricky". Imagine access to static data in
> different processes compared to access in different threads.
Of course. Again, the question of "mapping" (whatever that may mean)
a structure of processes to a structure of threads is too
system-dependent to discuss abstractly (and off-topic ..)
> I agree that it's a good design for a thread to be as a black box. Still a
> black box (in general) should have a complete interface containing input
> parameters specifications , output param , if it may throw an
> exception ...and in practice i would like to know if that black box (the
> thread ) is spawning other threads and is possible how many.
Well, maybe you would, but then it wouldn't be a black-box, would it ?
> If i know my app will run at maximum performance on the target system using X
> number of threads and i decide to start X threads and each one of this
> threads starts other threads then probably the performance will suffer.
Impossible to discuss in the absence of more system specific info.
Questions of "performance" (whatever that may mean) are difficult
enough even when you know what system you're talking about ...
> I do appreciate the parent child relation of QObjects and it's advantages but
> this seems like an overuse. Why not just declare the SubThread classes on the
> stack ? Am i missing something?
>
> MyThread::run()
> {
> SubThread1 thr1;
> SubThread2 thr2;
> thr1.start();
> thr2.start();
> thr1.wait();
> thr2.wait();
> }
You're missing the possibility that a design may need to create
threads dynamically at run time. Would it make sense for some
systems to be limited to a fixed number of processes at run time ?
Some systems need dynamically created threads for the same reasons.
> I hope I haven't said stupid things :)
No.
--
[ signature omitted ]
Thiago Macieira wrote:
> Stephen Collyer wrote:
>> Iulian M wrote:
>>> Out of curiosity why would you ever need a tree-like structure of
>>> threads ?
>> There are several reasons:
>
> You misunderstood the question. We're not asking why you need to have
> threads create threads that create sub-threads, etc.
This is way off-topic for this list, but AFAICS that was precisely
the question.
> We're asking why you
> need to have a Parent-Child relationship between QThread objects in the
> QObject sense of it.
>
> You can do without that and still accomplish your needs.
Indeed. However, I was led to surmise, from the fact that QThread
is a sub-class of QObject and that the ctor takes a parent pointer
that it could be done. So naturally I wanted to do it.
>> 1. Practical - I'm porting some code to Qt that already has a
>> tree-like structure of processes and that will map most cleanly
>> onto a tree-like structure of threads.
>
> You *can* have a tree-like structure of threads. But all QThread objects
> have to be created in the same thread (probably your main thread).
>
> The threads can be started from any thread once they are created.
>
>> 2. Theoretical - if you can't have a tree-like structure of threads,
>> you can only run single threaded code, since a Parent-Child structure
>> is already a tree. And if you allow Parent-Child, why should you
>> disallow Parent-Child-Child ?
>
> Huh? If you can't have a tree-like structure of threads, you can still use
> threads. It will just be a flat list.
I'm using the term "parent" in the sense of "spawning thread", and
"child" in the sense "spawned thread". My comment makes sense with
that in mind, though it could be considered tautological.
>> 3. Pragmatic - you've got it whether you like it or not, as Qt
>> allows it (as do other thread systems)
>>
>> 4. Good design - if you spawn a thread to do a job, good
>> engineering practice demands that it be a black box - you
>> should neither know nor care if it spawns sub-threads to
>> do its job.
>
> Good point.
>
> This being the case, you can do this:
>
> main thread:
> thr = new MyThread(QCoreApplication::instance());
> thr->start();
>
> MyThread::run()
> {
> QObject dummy;
> thr1 = new SubThread1(&dummy);
> thr2 = new SubThread2(&dummy);
> thr1->start();
> thr2->start();
>
> /* do something to make sure that both threads have finished, like: */
> thr1->wait();
> thr2->wait();
> }
>
> The code above created a three-level tree of QThread-based objects by
> dividing it in two trees. The dummy object in MyThread::run() is
> allocated on the stack, therefore it lives in that thread.
>
> It has no real QObject parent, but it is technically bound to MyThread's
> existence. It will be deleted before MyThread is, which is what the
> QObject object tree does for you.
That looks like an interesting solution to the original problem,
but I think that in the case of threads, it's easier to handle
memory management manually.
--
[ signature omitted ]
Hi,
I write class A that derives from class QGraphicsItem, so I need to realize
the pure virtual method boundingRect(). In which, I would like the returned
bounding rectangle would cover all children of the current A instance. So I
have thought I should use the childrenBoundingRect() method.
My code as follows:
=============================================
QRectF A::boundingRect() const{
double boundingWidth = 0;
double boundingHeight = 0;
//
if (condition()){
boundingWidth = childrenBoundingRect().width();
boundingHeight = childrenBoundingRect().height();
}
//
return QRectF(0, 0, boundingWidth, boundingHeight);
}
=============================================
where condition() is a member method of A that checks some certain condition.
But I have got the following error:
======================
error: passing âconst Aâ as âthisâ argument of âbool A::condition()â discards
qualifiers
======================
I do not know how to fix it. If you have any idea, please let me know.
Thank you very much.
Best regards,
.Viet Trung.
--
[ signature omitted ]
Hi Viet,
The compiler is saying that boundingRect is declared as const, but condition() is not declared as const. You either need to remove or add the const keyword.
Hope that helps,
Tony Rietwyk
> -----Original Message-----
> From: Do Viet Trung [mailto:viet.trung.do@xxxxxxxxxxxxxx]
> Sent: Sunday, 2 December 2007 21:02
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Problem with realizing boundingRect() of QGraphicsItem
>
>
> Hi,
>
> I write class A that derives from class QGraphicsItem, so I
> need to realize
> the pure virtual method boundingRect(). In which, I would
> like the returned
> bounding rectangle would cover all children of the current A
> instance. So I
> have thought I should use the childrenBoundingRect() method.
>
> My code as follows:
> =============================================
> QRectF A::boundingRect() const{
> double boundingWidth = 0;
> double boundingHeight = 0;
> //
> if (condition()){
> boundingWidth = childrenBoundingRect().width();
> boundingHeight = childrenBoundingRect().height();
> }
> //
> return QRectF(0, 0, boundingWidth, boundingHeight);
> }
> =============================================
> where condition() is a member method of A that checks some
> certain condition.
>
> But I have got the following error:
> ======================
> error: passing âconst Aâ as âthisâ argument of âbool
> A::condition()â discards
> qualifiers
> ======================
>
> I do not know how to fix it. If you have any idea, please let me know.
>
> Thank you very much.
>
> Best regards,
>
> .Viet Trung.
>
> --
> To unsubscribe - send a mail to
> qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the
> subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Hi Tony,
Thank you for your answer! It's helpful!
Best regards,
.Viet Trung.
On Sunday 02 December 2007 11:12, Tony Rietwyk wrote:
> Hi Viet,
>
> The compiler is saying that boundingRect is declared as const, but
> condition() is not declared as const. You either need to remove or add the
> const keyword.
>
> Hope that helps,
>
> Tony Rietwyk
>
> > -----Original Message-----
> > From: Do Viet Trung [mailto:viet.trung.do@xxxxxxxxxxxxxx]
> > Sent: Sunday, 2 December 2007 21:02
> > To: qt-interest@xxxxxxxxxxxxx
> > Subject: Problem with realizing boundingRect() of QGraphicsItem
> >
> >
> > Hi,
> >
> > I write class A that derives from class QGraphicsItem, so I
> > need to realize
> > the pure virtual method boundingRect(). In which, I would
> > like the returned
> > bounding rectangle would cover all children of the current A
> > instance. So I
> > have thought I should use the childrenBoundingRect() method.
> >
> > My code as follows:
> > =============================================
> > QRectF A::boundingRect() const{
> > double boundingWidth = 0;
> > double boundingHeight = 0;
> > //
> > if (condition()){
> > boundingWidth = childrenBoundingRect().width();
> > boundingHeight = childrenBoundingRect().height();
> > }
> > //
> > return QRectF(0, 0, boundingWidth, boundingHeight);
> > }
> > =============================================
> > where condition() is a member method of A that checks some
> > certain condition.
> >
> > But I have got the following error:
> > ======================
> > error: passing âconst Aâ as âthisâ argument of âbool
> > A::condition()â discards
> > qualifiers
> > ======================
> >
> > I do not know how to fix it. If you have any idea, please let me know.
> >
> > Thank you very much.
> >
> > Best regards,
> >
> > .Viet Trung.
> >
> > --
> > To unsubscribe - send a mail to
> > qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the
> > subject or the body.
> > List archive and information: http://lists.trolltech.com/qt-interest/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]