| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
Greetings, is there a technical reason why the sleep methods are protected? I am looking for something that works like Java's Thread.sleep(...) method. I think in Qt it would map to: QThread::currentThread()->sleep(...). I am quite sure I am missing something obvious so any gentle hints would be appreciated.
Cheers
-ian reinhart geiser
IMO this is an obvious design flaw. This is an open issue in the task tracker database (199843). Easy to solve by sub-classing, though. Philippe On Wed, 7 May 2008 17:40:56 -0400 Ian Geiser <igeiser@xxxxxxxxxxx> wrote: > Greetings, is there a technical reason why the sleep methods are protected? I am looking for something that works like Java's Thread.sleep(...) method. I think in Qt it would map to: QThread::currentThread()->sleep(...). I am quite sure I am missing something obvious so any gentle hints would be appreciated. > > Cheers > -ian reinhart geiser -- [ signature omitted ]
On Wednesday 07 May 2008 23:40:56 Ian Geiser wrote: > Greetings, is there a technical reason why the sleep methods are protected? Becouse people dont rtfm on thread enough. They 1) freeze the main thread and wonder why the heck the gui doesnt respond. 2) think threads are state engines 3) seriously believe everything will be fine and happy if you freeze an arbitary thread from some other thread. -- [ signature omitted ]
Right this iw why we need to have something like the code I posted. The point is not to sleep "any" thread. It is to sleep your current thread. Now maybe that's the part I am unclear about. I am sure there is an obvious way to do this I am just missing. -ian reinhart geiser -----Original Message----- From: Arvid Ephraim Picciani [mailto:aep@xxxxxxxxxxxxxxx] Sent: Wednesday, May 07, 2008 6:33 PM To: qt-interest@xxxxxxxxxxxxx Subject: Re: Sleeping a QThread On Wednesday 07 May 2008 23:40:56 Ian Geiser wrote: > Greetings, is there a technical reason why the sleep methods are protected? Becouse people dont rtfm on thread enough. They 1) freeze the main thread and wonder why the heck the gui doesnt respond. 2) think threads are state engines 3) seriously believe everything will be fine and happy if you freeze an arbitary thread from some other thread. -- [ signature omitted ]
Hi, > Right this iw why we need to have something like the code I posted. The point is not to sleep "any" thread. It is to sleep your current thread. Now maybe that's the part I am unclear about. I am sure there is an obvious way to do this I am just missing. If you need to sleep your own thread, then you're very often in the run() method of QThread and you do have access to the protected method sleep(). The rationale behind this design is avoiding writing: someOtherThread->sleep() -- [ signature omitted ]
No, as soon as you have a complex application, it's unlikely that your thread code is merely located to the run() fiunction or in any method inheriting a QThread object. Philippe On Thu, 08 May 2008 09:58:55 +0200 Dimitri <dimitri@xxxxxxxxxxxxx> wrote: > Hi, > > > Right this iw why we need to have something like the code I posted. The point is not to sleep "any" thread. It is to sleep your current thread. Now maybe that's the part I am unclear about. I am sure there is an obvious way to do this I am just missing. > > If you need to sleep your own thread, then you're very often in the run() > method of QThread and you do have access to the protected method sleep(). > > The rationale behind this design is avoiding writing: > someOtherThread->sleep() > > -- > Dimitri > > -- > 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, > No, as soon as you have a complex application, it's unlikely that your > thread code is merely located to the run() fiunction or in any method > inheriting a QThread object. True, I was just explaining the rationale behind the design. As you've already pointed out, there's already an open issue in the tracker and the design could be changed in Qt 5. On the other hand, if the application is complex, it shouldn't be that a hassle to override sleep() in a subclass. -- [ signature omitted ]
But I am not, I am in an object that has a lifetime only in the run method. I encapsulated all of my run code into its own object.
-ian reinhart geiser
-----Original Message-----
From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx]
Sent: Thursday, May 08, 2008 3:59 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Sleeping a QThread
Hi,
> Right this iw why we need to have something like the code I posted. The point is not to sleep "any" thread. It is to sleep your current thread. Now maybe that's the part I am unclear about. I am sure there is an obvious way to do this I am just missing.
If you need to sleep your own thread, then you're very often in the run()
method of QThread and you do have access to the protected method sleep().
The rationale behind this design is avoiding writing:
someOtherThread->sleep()
--
[ signature omitted ]
Hi, Since you have to subclass QThread anyway to implement the run method, I don't see the problem of reimplementing the sleep method as well or just adding a simple function to your subclassed QThread that accesses that function? If your object has a reference to the thread object somehow, I'd say this is trivial. André "Ian Geiser" <igeiser@xxxxxxxxxxx> wrote in message news:B57A220D1EE1644685BA9AD5C790D205121C89BC85@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > But I am not, I am in an object that has a lifetime only in the run > method. I encapsulated all of my run code into its own object. > -ian reinhart geiser > > -----Original Message----- > From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx] > Sent: Thursday, May 08, 2008 3:59 AM > To: qt-interest@xxxxxxxxxxxxx > Subject: Re: Sleeping a QThread > > Hi, > >> Right this iw why we need to have something like the code I posted. The >> point is not to sleep "any" thread. It is to sleep your current thread. >> Now maybe that's the part I am unclear about. I am sure there is an >> obvious way to do this I am just missing. > > If you need to sleep your own thread, then you're very often in the run() > method of QThread and you do have access to the protected method sleep(). > > The rationale behind this design is avoiding writing: > someOtherThread->sleep() > > -- > Dimitri > > -- > 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 ]
I don't follow your argument because IMO Thread programming is a topic for serious programmers, and not understanding this basic sleep behaviour is... just forget it all together! (there are many more subblte ways to create thead related bugs!). BTW, Qt has also this similar API: void QTest::qSleep ( int ms ) Philippe On Thu, 8 May 2008 00:33:22 +0200 Arvid Ephraim Picciani <aep@xxxxxxxxxxxxxxx> wrote: > On Wednesday 07 May 2008 23:40:56 Ian Geiser wrote: > > > Greetings, is there a technical reason why the sleep methods are protected? > > Becouse people dont rtfm on thread enough. They > 1) freeze the main thread and wonder why the heck the gui doesnt respond. > 2) think threads are state engines > 3) seriously believe everything will be fine and happy if you freeze an > arbitary thread from some other thread. > -- > best regards/Mit freundlichen Grüßen > Arvid Ephraim Picciani > > -- > 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 ]
> 1) freeze the main thread and wonder why the heck the gui doesnt
respond.
I can easily do this without using a public sleep() method ... It can be
very helpful in some situations (i.e. certain non-GUI applications) to
have a "public static QThread::sleep()" handy. We just subclassed it, made
it public and put it into a library :)
Often (not always though) the need for public sleeps() is a sign of bad
design - but really depends on what you are doing.
> 2) think threads are state engines
Aren't they? *joking*
> 3) seriously believe everything will be fine and happy if you freeze an
> arbitary thread from some other thread.
public static QThread::freezeRandomThread() { ... } *shudder* ;-)
Regards,
Malte
--
[ signature omitted ]
Am Mittwoch, 7. Mai 2008 schrieb Ian Geiser: > Greetings, is there a technical reason why the sleep methods are protected? > I am looking for something that works like Java's Thread.sleep(...) > method. I think in Qt it would map to: > QThread::currentThread()->sleep(...). I am quite sure I am missing > something obvious so any gentle hints would be appreciated. I came across this "problem" too. And I realized that the only occasions I "needed" a sleep-function was when waiting for some flaws in my design. So I decided to fix them instead of making the whole app slower with some strange sleep()-calls. The only cases where I need to sleep is when waiting in the main-thread (before the gui starts) for the startup of some child-threads. And there ::usleep() proves to be usable. And I am sure there is a more Qt-way of implementing this (probably QWaitCondition), I just didn't yet look at it... Arnold -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.