Re: [Interest] Qthread from QFuture?

Thanks for the info ~~Scott Original message From: Thiago Macieira Date: 1/5/22 4:31 AM (GMT-08:00) To: interest@qt-project.org Cc: Scott Bloom Subject: Re: [Interest] Qthread from QFuture? On Tuesday, 4 January 2022 22:01:20 -03 Scott Bloom wrote: > I appreciate

Re: [Interest] Qthread from QFuture?

On Tuesday, 4 January 2022 22:01:20 -03 Scott Bloom wrote: > I appreciate the information. However, I don’t understand why a QFuture > created by QtConcurrent::run, if it can tell isRunning, why it cant return > the QThread its using? Because you don't have a use-case for using that pointer. What

Re: [Interest] Qthread from QFuture?

On Wed, Jan 5, 2022 at 3:03 AM Scott Bloom wrote: > Its such a nice simple interface for launching a background thread and > asynchronously being notified when it finishes 😊 > The point is that it doesn't start a thread at all, not necessarily. The threads are pooled and your job is queued for e

Re: [Interest] Qthread from QFuture?

ubject: Re: [Interest] Qthread from QFuture? On Tuesday, 4 January 2022 16:07:05 -03 Scott Bloom wrote: > Is there anyway to get (if it even exists) a QThread from a > QFuture/QFutureWatcher? You can't get it because a thread will not have been assigned until the job starts. The thread that

Re: [Interest] Qthread from QFuture?

On Tuesday, 4 January 2022 16:07:05 -03 Scott Bloom wrote: > Is there anyway to get (if it even exists) a QThread from a > QFuture/QFutureWatcher? You can't get it because a thread will not have been assigned until the job starts. The thread that ends up running your job may be any of the threads

Re: [Interest] Qthread from QFuture?

I don't think QFuture/QFutureWatcher would have such an API. I guess you could query what thread it is at the start of the function you run with QtConcurrent::run and communicate that to your main thread. Elvis Den tis 4 jan. 2022 kl 20:08 skrev Scott Bloom : > > Is there anyway to get (if it eve

[Interest] Qthread from QFuture?

Is there anyway to get (if it even exists) a QThread from a QFuture/QFutureWatcher? The main issue, and I know this going to sound horrible, I would like to kill/terminate the thread, I know its safe 😊 (famous last words).. Here is what im doing, maybe someone has a better solution (Im sure of

Re: [Interest] QThread & sleep on QMutex

On 2015-07-30 01:43, Igor Mironchik wrote: > On 30.07.2015 00:06, Matthew Woehlke wrote: >> Why are you doing this? If the intent is just to make the thread sleep, >> why not use QThread::msleep? > > Because in Qt 4 QThread::sleep is protected. You failed to mention that you are using Qt 4.x :-).

Re: [Interest] QThread & sleep on QMutex

> > And my question is just theoretical: is this approach good or such > sleep() implementation not so good and why? I.e. will such sleep() > release processor's time for another thread or not? > Using sleep() will allow the processor to work on a different thread. The issue is that sleep() will m

Re: [Interest] QThread & sleep on QMutex

Hi, On 30.07.2015 11:31, Tony Rietwyk wrote: > Igor wrote: > >> Because in Qt 4 QThread::sleep is protected. > You can unprotect it by deriving your own class from QThread and making > whichever static methods public! As long as you are aware of the pitfalls > (don't sleep in main thread, etc.),

Re: [Interest] QThread & sleep on QMutex

Igor wrote: > Because in Qt 4 QThread::sleep is protected. You can unprotect it by deriving your own class from QThread and making whichever static methods public! As long as you are aware of the pitfalls (don't sleep in main thread, etc.), and much easier than messing with locks just to gain a

Re: [Interest] QThread & sleep on QMutex

On 30.07.2015 00:06, Matthew Woehlke wrote: > On 2015-07-29 16:55, Igor Mironchik wrote: >> I hope that in this list I will find experts of synchronization and so on. >> >> My question: is it good to make thread's sleep on mutex like this? >> >> QMutex mutex; >> mutex.lock(); >> mutex.tryLock( in

Re: [Interest] QThread & sleep on QMutex

On Wednesday 29 July 2015 23:55:30 Igor Mironchik wrote: > Hi, > > I hope that in this list I will find experts of synchronization and so on. > > My question: is it good to make thread's sleep on mutex like this? No. > > QMutex mutex; > mutex.lock(); > mutex.tryLock( int msecs ); // This will

Re: [Interest] QThread & sleep on QMutex

On 2015-07-29 16:55, Igor Mironchik wrote: > I hope that in this list I will find experts of synchronization and so on. > > My question: is it good to make thread's sleep on mutex like this? > > QMutex mutex; > mutex.lock(); > mutex.tryLock( int msecs ); // This will make sleep for the given time

[Interest] QThread & sleep on QMutex

Hi, I hope that in this list I will find experts of synchronization and so on. My question: is it good to make thread's sleep on mutex like this? QMutex mutex; mutex.lock(); mutex.tryLock( int msecs ); // This will make sleep for the given timeout. Or it's not so good idea because thread will n

Re: [Interest] QThread

On Tue, Mar 25, 2014 at 2:49 AM, Alan Ezust wrote: > If you're using Qt 5.2 or later, there is a new API you can use. > > Call isInterruptionRequested() in your loop, > > http://qt-project.org/doc/qt-5/qthread.html#isInterruptionRequested > > And call requestInterruption() from outside. > > http:

Re: [Interest] QThread

> Thanks again > > > > -Original Message- > > From: > > interest-bounces+graham.labdon=avalonsciences@qt-project.org[mailto: > interest-bounces+graham.labdon=avalonsciences@qt-project.org] On > Behalf Of André Somers > > Sent: 24 March 20

Re: [Interest] QThread

Em seg 24 mar 2014, às 09:49:07, Bob Hood escreveu: > I actually use the "volatile" tag to tell the compiler that it cannot > optimize (i.e., make compile-time assumptions about) the variable that it > decorates. Does std::atomic have the same meaning for optimizations? I > can't get a clear pictu

Re: [Interest] QThread

>> To: Thiago Macieira; interest@qt-project.org >> Subject: Re: [Interest] QThread >> >> [...] >> I actually use the "volatile" tag to tell the compiler that it cannot >> optimize (i.e., >> make compile-time assumptions about) the variable that it

Re: [Interest] QThread

2014 4:49 PM >> To: Thiago Macieira; interest@qt-project.org >> Subject: Re: [Interest] QThread >> >> [...] >> I actually use the "volatile" tag to tell the compiler that it cannot >> optimize (i.e., >> make compile-time assumptions about) the var

Re: [Interest] QThread

> -Original Message- > From: interest-bounces+kai.koehne=digia@qt-project.org > [mailto:interest-bounces+kai.koehne=digia@qt-project.org] On Behalf Of > Bob Hood > Sent: Monday, March 24, 2014 4:49 PM > To: Thiago Macieira; interest@qt-project.org > S

Re: [Interest] QThread

On 3/24/2014 9:30 AM, Thiago Macieira wrote: > Em seg 24 mar 2014, às 16:27:06, André Somers escreveu: >> The point is, that usually you don't _need_ synchronization for this >> purpose, and using synchronization does come at a cost. It is usually >> not critical that the worker thread stops imme

Re: [Interest] QThread

Em seg 24 mar 2014, às 16:27:06, André Somers escreveu: > The point is, that usually you don't _need_ synchronization for this > purpose, and using synchronization does come at a cost. It is usually > not critical that the worker thread stops immediately when signalled, > just that it stops soon

Re: [Interest] QThread

Etienne Sandré-Chardonnal schreef op 24-3-2014 16:11: volatile is not providing synchronization guarantees in the standard. Even if it may work on most platforms with bool, this is not a good practice. std::atomic or QAtomicInt will do the job. The point is, that usually you don't _need_ syn

Re: [Interest] QThread

Em seg 24 mar 2014, às 11:38:54, Graham Labdon escreveu: > m_generatorThread = new GeneratorThread(this); > > Then I call moveToThread and make the connections- > m_generatorThread->moveToThread(m_thread) I'm pretty sure that moveToThread printed a warning and failed to move, since your object

Re: [Interest] QThread

volatile is not providing synchronization guarantees in the standard. Even if it may work on most platforms with bool, this is not a good practice. std::atomic or QAtomicInt will do the job. 2014-03-24 13:40 GMT+01:00 André Somers : > Protecting it with a mutex is usually not needed, and it doe

Re: [Interest] QThread

Thanks all -Original Message- From: interest-bounces+graham.labdon=avalonsciences@qt-project.org [mailto:interest-bounces+graham.labdon=avalonsciences@qt-project.org] On Behalf Of André Somers Sent: 24 March 2014 12:40 To: interest@qt-project.org Subject: Re: [Interest] QThread

Re: [Interest] QThread

[mailto:interest-bounces+graham.labdon=avalonsciences@qt-project.org] On >> Behalf Of André Somers >> Sent: 24 March 2014 12:06 >> To: interest@qt-project.org >> Subject: Re: [Interest] QThread >> >> Graham Labdon schreef op 24-3-2014 12:38: >>> Hi >>&

Re: [Interest] QThread

> Sent: 24 March 2014 12:06 > To: interest@qt-project.org > Subject: Re: [Interest] QThread > > Graham Labdon schreef op 24-3-2014 12:38: >> Hi >> I am experimenting with QThreads >> The basic idea is to have a thread performing some task and to have a >> button

Re: [Interest] QThread

don=avalonsciences@qt-project.org] On Behalf Of André Somers Sent: 24 March 2014 12:06 To: interest@qt-project.org Subject: Re: [Interest] QThread Graham Labdon schreef op 24-3-2014 12:38: > Hi > I am experimenting with QThreads > The basic idea is to have a thread performing some task a

Re: [Interest] QThread

Graham Labdon schreef op 24-3-2014 12:38: > Hi > I am experimenting with QThreads > The basic idea is to have a thread performing some task and to have a button > on the UI that can stop this operation > > So I have a class that will perform the operation called GeneratorThread that > has a start

Re: [Interest] QThread

2014-03-24 12:38 GMT+01:00 Graham Labdon : > Hi > I am experimenting with QThreads > The basic idea is to have a thread performing some task and to have a button > on the UI that can stop this operation > > So I have a class that will perform the operation called GeneratorThread that > has a star

[Interest] QThread

Hi I am experimenting with QThreads The basic idea is to have a thread performing some task and to have a button on the UI that can stop this operation So I have a class that will perform the operation called GeneratorThread that has a start slot In the main ui class I create an instance of the

Re: [Interest] QThread, correct exit.

28.09.2013 13:57, Alexander Syvak пишет: Each thread emits blocking queued singnals to the main thread where button stop executes the code in the previous mail. 2013/9/28 Mandeep Sandhu > On Sat, Sep 28, 2013 at 3:14 PM, Alexander Syvak mailto:ale

Re: [Interest] QThread, correct exit.

Each thread emits blocking queued singnals to the main thread where button stop executes the code in the previous mail. 2013/9/28 Mandeep Sandhu > > On Sat, Sep 28, 2013 at 3:14 PM, Alexander Syvak > wrote: > >> Hello, >> >> how to correctly stop a QThread execution? >> >> I am using >> thread

Re: [Interest] QThread, correct exit.

On Sat, Sep 28, 2013 at 3:14 PM, Alexander Syvak wrote: > Hello, > > how to correctly stop a QThread execution? > > I am using > thread.quit(); > > thread.terminate(); > > Don't terminate. Quitting and waiting should be sufficient. > thread.wait(500); > > Without terminate() thread wait forever.

[Interest] QThread, correct exit.

Hello, how to correctly stop a QThread execution? I am using thread.quit(); thread.terminate(); thread.wait(500); Without terminate() thread wait forever. Each thread is executing an event loop only (object is moved into thread). ___ Interest mailing

Re: [Interest] QThread and QPixmap::grabWindow()

I guess my suggestion was not clear. Create a slot where: - QPixmap::grabWindow( QApplication::desktop()->winId() ); will be called. - QPixmap is converted to QImage - Signal and slot may contain reference to the QImage as a parameter, so you can access filled QImage after signal is emitted..

Re: [Interest] QThread and QPixmap::grabWindow()

It's done as following, the thread wrapper (the class holding the QThread object and the pointer to be moved into the thread-worker) connects the class to be moved into the worker-thread with the main thread slot 'make_screenshot(pointer to the class which emits the signal)'. The main thread slot p

Re: [Interest] QThread and QPixmap::grabWindow()

Am 08.08.2013 00:11, schrieb Alexander Syvak: [...] auto const this_thread = this->thread (); moveToThread (QApplication::instance()->thread()); screenshot = QPixmap::grabWindow( QApplication::desktop()->winId() ); moveToThread(this_thread); [...] I think you might have a proble

Re: [Interest] QThread and QPixmap::grabWindow()

On quinta-feira, 8 de agosto de 2013 01:11:09, Alexander Syvak wrote: [cut all code] Answering your subject: you cannot mix QThread and QPixmap. QPixmap can only be used from the main (GUI) thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Tech

Re: [Interest] QThread and QPixmap::grabWindow()

As far as I understand you need to make sure that window is grabbed in the main thread. So the clean way to do it - do it in the main threat without changing affinity . and wait until picture is taken in the threat you need a picture at. This will also remove race conditions you are facing - your

[Interest] QThread and QPixmap::grabWindow()

Hello, there's a need for each thread to make screenshots and to compare them with loaded picture using QImage. Since there's only on GUI thread, I moved the the thread context to the main thread to make the screenshot in there. Here's the code snipper from the worker-threads: QPixmap scr

Re: [Interest] QThread and sleep

On terça-feira, 19 de março de 2013 15.15.31, Hugo Drumond Jacob wrote: > 2013/3/19 Thiago Macieira : > > On terça-feira, 19 de março de 2013 14.56.47, Hugo Drumond Jacob wrote: > >> No problem! In fact, we are using! It's just a question about > >> QThread::wait and QThread::sleep: "It's safe use

Re: [Interest] QThread and sleep

2013/3/19 Thiago Macieira : > On terça-feira, 19 de março de 2013 14.56.47, Hugo Drumond Jacob wrote: >> No problem! In fact, we are using! It's just a question about >> QThread::wait and QThread::sleep: "It's safe use QThread::wait in >> other situation that not synchronously QThread::terminate ?

Re: [Interest] QThread and sleep

On terça-feira, 19 de março de 2013 14.56.47, Hugo Drumond Jacob wrote: > No problem! In fact, we are using! It's just a question about > QThread::wait and QThread::sleep: "It's safe use QThread::wait in > other situation that not synchronously QThread::terminate ?" and you > already answered: yes

Re: [Interest] QThread and sleep

2013/3/19 Thiago Macieira : > On terça-feira, 19 de março de 2013 14.14.20, Hugo Drumond Jacob wrote: >> > Yes: don't sleep. >> >> In fact, we have a class inherited of QThread that can change the >> default scheduler of thread to use Linux SCHED_FIFO and really change >> the thread priority. We ar

Re: [Interest] QThread and sleep

On terça-feira, 19 de março de 2013 14.14.20, Hugo Drumond Jacob wrote: > > Yes: don't sleep. > > In fact, we have a class inherited of QThread that can change the > default scheduler of thread to use Linux SCHED_FIFO and really change > the thread priority. We are using that way because we need to

Re: [Interest] QThread and sleep

Thanks Thiago! 2013/3/19 Thiago Macieira : > On terça-feira, 19 de março de 2013 10.37.56, Hugo Drumond Jacob wrote: >> Hi folks! >> >> Today some doubt has ocurred on my office. Suppose that for some >> reason we need to sleep a thread (not the main thread) for some time > > Suppose that you're w

Re: [Interest] QThread and sleep

On terça-feira, 19 de março de 2013 10.37.56, Hugo Drumond Jacob wrote: > Hi folks! > > Today some doubt has ocurred on my office. Suppose that for some > reason we need to sleep a thread (not the main thread) for some time Suppose that you're wrong and you came to the wrong solution that sleeping

[Interest] QThread and sleep

Hi folks! Today some doubt has ocurred on my office. Suppose that for some reason we need to sleep a thread (not the main thread) for some time (eg. 100 ms). The QThread::wait(int) "provides similar functionality to the POSIX pthread_join()" and this don't will sleep the target thread, but the cal