Re: [Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

QRunnables with QThreadPool seem to work great in my case.
I am instantitating my main worker class inside the QRunnable now to be 
able send signals via that (e.g. runnable.worker.signal.emit()).
I tried multiple inheritance to just have one QRunnable class that can 
emit signals, but that didn't work, e.g.:

class MyRunable(QtCore.QObject, QtCore.QRunnable()

But I'm happy with my solution now, so thanks everybody for contributing.

frank

On 20/01/17 3:08 PM, Thiago Macieira wrote:

On quinta-feira, 19 de janeiro de 2017 07:55:12 PST Elvis Stansvik wrote:

Frank, another threading approach in Qt which we haven't mentioned yet
is QtConcurrent. I use that myself in an application where I had to
load a series of large tomographic volumes using VTK (so blocking
I/O). It might not be a good fit for your use case, but thought I
should mention it for brevity.

Or you can use Thread Building Blocks too.



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Thiago Macieira]

On quinta-feira, 19 de janeiro de 2017 07:55:12 PST Elvis Stansvik wrote:
> Frank, another threading approach in Qt which we haven't mentioned yet
> is QtConcurrent. I use that myself in an application where I had to
> load a series of large tomographic volumes using VTK (so blocking
> I/O). It might not be a good fit for your use case, but thought I
> should mention it for brevity.

Or you can use Thread Building Blocks too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

Thanks Elvis, much appreciated!


On 19/01/17 7:55 PM, Elvis Stansvik wrote:

2017-01-19 1:10 GMT+01:00 Thiago Macieira :

On quarta-feira, 18 de janeiro de 2017 20:04:41 PST Elvis Stansvik wrote:

If you have one QThread that depends on the completion of another,
then no, I don't think there's a convenient API in Qt to express that
relationship and run the threads in sequence. You'll have to string
them together yourself, or maybe use something else like Threadweaver.
I could be wrong of course

You can always chain-connect one thread's finished() signal to the other's
start() slot.

Yes sorry, should have been more explicit, that's what I meant with
"string them together".

Frank, another threading approach in Qt which we haven't mentioned yet
is QtConcurrent. I use that myself in an application where I had to
load a series of large tomographic volumes using VTK (so blocking
I/O). It might not be a good fit for your use case, but thought I
should mention it for brevity.

Elvis


But that's unnecessary overhead: stopping and starting threads. You should do
like Elvis says and just reuse the thread.

--
Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Elvis Stansvik]

2017-01-19 1:10 GMT+01:00 Thiago Macieira :
> On quarta-feira, 18 de janeiro de 2017 20:04:41 PST Elvis Stansvik wrote:
>> If you have one QThread that depends on the completion of another,
>> then no, I don't think there's a convenient API in Qt to express that
>> relationship and run the threads in sequence. You'll have to string
>> them together yourself, or maybe use something else like Threadweaver.
>> I could be wrong of course
>
> You can always chain-connect one thread's finished() signal to the other's
> start() slot.

Yes sorry, should have been more explicit, that's what I meant with
"string them together".

Frank, another threading approach in Qt which we haven't mentioned yet
is QtConcurrent. I use that myself in an application where I had to
load a series of large tomographic volumes using VTK (so blocking
I/O). It might not be a good fit for your use case, but thought I
should mention it for brevity.

Elvis

>
> But that's unnecessary overhead: stopping and starting threads. You should do
> like Elvis says and just reuse the thread.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

OK, thanks Thiago and Elvis.
I think I got the picture now and can proceed knowing I'm not heading 
into a dead end.


Cheers,
frank

On 19/01/17 1:10 PM, Thiago Macieira wrote:

On quarta-feira, 18 de janeiro de 2017 20:04:41 PST Elvis Stansvik wrote:

If you have one QThread that depends on the completion of another,
then no, I don't think there's a convenient API in Qt to express that
relationship and run the threads in sequence. You'll have to string
them together yourself, or maybe use something else like Threadweaver.
I could be wrong of course

You can always chain-connect one thread's finished() signal to the other's
start() slot.

But that's unnecessary overhead: stopping and starting threads. You should do
like Elvis says and just reuse the thread.



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Thiago Macieira]

On quarta-feira, 18 de janeiro de 2017 20:04:41 PST Elvis Stansvik wrote:
> If you have one QThread that depends on the completion of another,
> then no, I don't think there's a convenient API in Qt to express that
> relationship and run the threads in sequence. You'll have to string
> them together yourself, or maybe use something else like Threadweaver.
> I could be wrong of course 

You can always chain-connect one thread's finished() signal to the other's 
start() slot.

But that's unnecessary overhead: stopping and starting threads. You should do 
like Elvis says and just reuse the thread.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

Thanks Elvis.
And my apologies (especially to Thiago) for posting a misleading and 
incopmlete question.


I have been playing with converting to QRunner which seems to work fine 
(haven't tested it thoroughly though).
I will have a look at QNetworkAccessManager so I can compare the 
approaches, thanks for the tip.


Cheers,
frank

On 19/01/17 8:12 AM, Elvis Stansvik wrote:

2017-01-18 20:11 GMT+01:00 Elvis Stansvik :

2017-01-18 20:04 GMT+01:00 Elvis Stansvik :

2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx :

Hi Thiago,

thanks for your quick reply. I will try and give some more context:
I use the python requests module inside my PySide app to post requests to a
website. Some of those requests return a lot of data that I need to parse to
be able to show progress, other requests are file downloads that I need
progress bars for as they stream onto disk.
I had tried to not use threads and use QApplication.processEvents() for each
data chunk downloaded, but that made the download about 4-5 times slower.
Introducing threading made a huge difference.

Right, you won't get a good result with that approach. It's always
good to be up front with any special circumstances like this (using a
networking API that does not run on top of the Qt event loop).


My app can download a list of files at the same time. Depending on the
situation and the user request, the list of files to be downloaded can
happen asynchronously, in other situations they need to be downloaded one
after the other.

I think this is what confused Thiago: What you mean is sequential (as
opposed to parallell), not synchronous.

If you have one QThread that depends on the completion of another,
then no, I don't think there's a convenient API in Qt to express that
relationship and run the threads infrom sequence. You'll have to string
them together yourself, or maybe use something else like Threadweaver.
I could be wrong of course :)

Another approach is of course to ditch the threading and use the
asyncronous QNetworkAccessManager from Qt, instead of using the Python
requests module. You can use the downloadProgress/uploadProgress of

downloadProgress/uploadProgress *signals*.


the QNetworkReply you get from get(..) or post(..) if you want to show
progress (haven't used it myself).

Elvis


Elvis


All I can tell you is that you don't need to do what you're trying to do,
since you don't need threads in the first place.

If I can avoid threads to do the above I would be more than happy to adjust
and get rid of them again, but I haven't managed to find a non-threaded
approach that doesn't slow down the download significantly.

Cheers,
frank


On 18/01/17 6:26 PM, Thiago Macieira wrote:

On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
wrote:

Hi,

I got another threading question for the pros out there:

In  my current application I am using QThread objects and
QObject.moveToThread() to enable my GUI to download multiple files while
updating progress bars in the main event loop. This is the respective

As usual, the usual disclaimer: you do not need threads to do networking
or
file I/O. The combined overhead of the networking I/O and saving of the
files is
unlikely to overwhelm the event loop to the point that the progress bar
can't
update smoothly.

I'm not saying impossible, but it's unlikely.


snippet of code:
   self.worker = MyClass()
   self.workerThread = QtCore.QThread()
   self.worker.moveToThread(self.workerThread)

The trouble is when the user wants to download multiple files at once.
In my current implementation that all works fine and I see multiple
progress bars do there thing.
However, there are cases when I need to force the download threads to be
synchronous. I had hoped that I can use QThreadPool with QThreads, but
turns out I need QRunnables in this case, and those don't have the same
signals as QThread.

Why do you need to force them to be synchronous? And synchronous with
what?
With each other? Or do you mean sync() in the file saving?

Finally, what does being synchronous have to do with signals?


So my question is:
Is there a good way to use QThreads in a queue which is controlled by
the main thread, or should I re-write my code and subclass QRunnable to
add the signals I need (i.e. the ones that QThread has by default)?

The whole point of QThread is that the code it runs is independent of
anything
else. Only the OS scheduler decides when it's time to run it or suspend
it.


In the latter case I guess I'd have to inherit from both QObject and
QRunnable, is this ok?

Right.

But we still don't understand what you're trying to do. All I can tell you
is
that you don't need to do what you're trying to do, since you don't need
threads in the first place.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Elvis Stansvik]

2017-01-18 20:11 GMT+01:00 Elvis Stansvik :
> 2017-01-18 20:04 GMT+01:00 Elvis Stansvik :
>> 2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx :
>>> Hi Thiago,
>>>
>>> thanks for your quick reply. I will try and give some more context:
>>> I use the python requests module inside my PySide app to post requests to a
>>> website. Some of those requests return a lot of data that I need to parse to
>>> be able to show progress, other requests are file downloads that I need
>>> progress bars for as they stream onto disk.
>>> I had tried to not use threads and use QApplication.processEvents() for each
>>> data chunk downloaded, but that made the download about 4-5 times slower.
>>> Introducing threading made a huge difference.
>>
>> Right, you won't get a good result with that approach. It's always
>> good to be up front with any special circumstances like this (using a
>> networking API that does not run on top of the Qt event loop).
>>
>>>
>>> My app can download a list of files at the same time. Depending on the
>>> situation and the user request, the list of files to be downloaded can
>>> happen asynchronously, in other situations they need to be downloaded one
>>> after the other.
>>
>> I think this is what confused Thiago: What you mean is sequential (as
>> opposed to parallell), not synchronous.
>>
>> If you have one QThread that depends on the completion of another,
>> then no, I don't think there's a convenient API in Qt to express that
>> relationship and run the threads infrom sequence. You'll have to string
>> them together yourself, or maybe use something else like Threadweaver.
>> I could be wrong of course :)
>
> Another approach is of course to ditch the threading and use the
> asyncronous QNetworkAccessManager from Qt, instead of using the Python
> requests module. You can use the downloadProgress/uploadProgress of

downloadProgress/uploadProgress *signals*.

> the QNetworkReply you get from get(..) or post(..) if you want to show
> progress (haven't used it myself).
>
> Elvis
>
>>
>> Elvis
>>
>>>
>All I can tell you is that you don't need to do what you're trying to do,
> since you don't need threads in the first place.
>>> If I can avoid threads to do the above I would be more than happy to adjust
>>> and get rid of them again, but I haven't managed to find a non-threaded
>>> approach that doesn't slow down the download significantly.
>>>
>>> Cheers,
>>> frank
>>>
>>>
>>> On 18/01/17 6:26 PM, Thiago Macieira wrote:

 On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
 wrote:
>
> Hi,
>
> I got another threading question for the pros out there:
>
> In  my current application I am using QThread objects and
> QObject.moveToThread() to enable my GUI to download multiple files while
> updating progress bars in the main event loop. This is the respective

 As usual, the usual disclaimer: you do not need threads to do networking
 or
 file I/O. The combined overhead of the networking I/O and saving of the
 files is
 unlikely to overwhelm the event loop to the point that the progress bar
 can't
 update smoothly.

 I'm not saying impossible, but it's unlikely.

> snippet of code:
>   self.worker = MyClass()
>   self.workerThread = QtCore.QThread()
>   self.worker.moveToThread(self.workerThread)
>
> The trouble is when the user wants to download multiple files at once.
> In my current implementation that all works fine and I see multiple
> progress bars do there thing.
> However, there are cases when I need to force the download threads to be
> synchronous. I had hoped that I can use QThreadPool with QThreads, but
> turns out I need QRunnables in this case, and those don't have the same
> signals as QThread.

 Why do you need to force them to be synchronous? And synchronous with
 what?
 With each other? Or do you mean sync() in the file saving?

 Finally, what does being synchronous have to do with signals?

> So my question is:
> Is there a good way to use QThreads in a queue which is controlled by
> the main thread, or should I re-write my code and subclass QRunnable to
> add the signals I need (i.e. the ones that QThread has by default)?

 The whole point of QThread is that the code it runs is independent of
 anything
 else. Only the OS scheduler decides when it's time to run it or suspend
 it.

> In the latter case I guess I'd have to inherit from both QObject and
> QRunnable, is this ok?

 Right.

 But we still don't understand what you're trying to do. All I can tell you
 is
 that you don't need to do what you're trying to do, since you don't need
 threads in the first place.

>>>
>>> ___
>>> Interest mailing 

Re: [Interest] QThreadPool functionality for QThreads

[Elvis Stansvik]

2017-01-18 20:04 GMT+01:00 Elvis Stansvik :
> 2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx :
>> Hi Thiago,
>>
>> thanks for your quick reply. I will try and give some more context:
>> I use the python requests module inside my PySide app to post requests to a
>> website. Some of those requests return a lot of data that I need to parse to
>> be able to show progress, other requests are file downloads that I need
>> progress bars for as they stream onto disk.
>> I had tried to not use threads and use QApplication.processEvents() for each
>> data chunk downloaded, but that made the download about 4-5 times slower.
>> Introducing threading made a huge difference.
>
> Right, you won't get a good result with that approach. It's always
> good to be up front with any special circumstances like this (using a
> networking API that does not run on top of the Qt event loop).
>
>>
>> My app can download a list of files at the same time. Depending on the
>> situation and the user request, the list of files to be downloaded can
>> happen asynchronously, in other situations they need to be downloaded one
>> after the other.
>
> I think this is what confused Thiago: What you mean is sequential (as
> opposed to parallell), not synchronous.
>
> If you have one QThread that depends on the completion of another,
> then no, I don't think there's a convenient API in Qt to express that
> relationship and run the threads infrom sequence. You'll have to string
> them together yourself, or maybe use something else like Threadweaver.
> I could be wrong of course :)

Another approach is of course to ditch the threading and use the
asyncronous QNetworkAccessManager from Qt, instead of using the Python
requests module. You can use the downloadProgress/uploadProgress of
the QNetworkReply you get from get(..) or post(..) if you want to show
progress (haven't used it myself).

Elvis

>
> Elvis
>
>>
All I can tell you is that you don't need to do what you're trying to do,
 since you don't need threads in the first place.
>> If I can avoid threads to do the above I would be more than happy to adjust
>> and get rid of them again, but I haven't managed to find a non-threaded
>> approach that doesn't slow down the download significantly.
>>
>> Cheers,
>> frank
>>
>>
>> On 18/01/17 6:26 PM, Thiago Macieira wrote:
>>>
>>> On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
>>> wrote:

 Hi,

 I got another threading question for the pros out there:

 In  my current application I am using QThread objects and
 QObject.moveToThread() to enable my GUI to download multiple files while
 updating progress bars in the main event loop. This is the respective
>>>
>>> As usual, the usual disclaimer: you do not need threads to do networking
>>> or
>>> file I/O. The combined overhead of the networking I/O and saving of the
>>> files is
>>> unlikely to overwhelm the event loop to the point that the progress bar
>>> can't
>>> update smoothly.
>>>
>>> I'm not saying impossible, but it's unlikely.
>>>
 snippet of code:
   self.worker = MyClass()
   self.workerThread = QtCore.QThread()
   self.worker.moveToThread(self.workerThread)

 The trouble is when the user wants to download multiple files at once.
 In my current implementation that all works fine and I see multiple
 progress bars do there thing.
 However, there are cases when I need to force the download threads to be
 synchronous. I had hoped that I can use QThreadPool with QThreads, but
 turns out I need QRunnables in this case, and those don't have the same
 signals as QThread.
>>>
>>> Why do you need to force them to be synchronous? And synchronous with
>>> what?
>>> With each other? Or do you mean sync() in the file saving?
>>>
>>> Finally, what does being synchronous have to do with signals?
>>>
 So my question is:
 Is there a good way to use QThreads in a queue which is controlled by
 the main thread, or should I re-write my code and subclass QRunnable to
 add the signals I need (i.e. the ones that QThread has by default)?
>>>
>>> The whole point of QThread is that the code it runs is independent of
>>> anything
>>> else. Only the OS scheduler decides when it's time to run it or suspend
>>> it.
>>>
 In the latter case I guess I'd have to inherit from both QObject and
 QRunnable, is this ok?
>>>
>>> Right.
>>>
>>> But we still don't understand what you're trying to do. All I can tell you
>>> is
>>> that you don't need to do what you're trying to do, since you don't need
>>> threads in the first place.
>>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Elvis Stansvik]

2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx :
> Hi Thiago,
>
> thanks for your quick reply. I will try and give some more context:
> I use the python requests module inside my PySide app to post requests to a
> website. Some of those requests return a lot of data that I need to parse to
> be able to show progress, other requests are file downloads that I need
> progress bars for as they stream onto disk.
> I had tried to not use threads and use QApplication.processEvents() for each
> data chunk downloaded, but that made the download about 4-5 times slower.
> Introducing threading made a huge difference.

Right, you won't get a good result with that approach. It's always
good to be up front with any special circumstances like this (using a
networking API that does not run on top of the Qt event loop).

>
> My app can download a list of files at the same time. Depending on the
> situation and the user request, the list of files to be downloaded can
> happen asynchronously, in other situations they need to be downloaded one
> after the other.

I think this is what confused Thiago: What you mean is sequential (as
opposed to parallell), not synchronous.

If you have one QThread that depends on the completion of another,
then no, I don't think there's a convenient API in Qt to express that
relationship and run the threads in sequence. You'll have to string
them together yourself, or maybe use something else like Threadweaver.
I could be wrong of course :)

Elvis

>
>>>All I can tell you is that you don't need to do what you're trying to do,
>>> since you don't need threads in the first place.
> If I can avoid threads to do the above I would be more than happy to adjust
> and get rid of them again, but I haven't managed to find a non-threaded
> approach that doesn't slow down the download significantly.
>
> Cheers,
> frank
>
>
> On 18/01/17 6:26 PM, Thiago Macieira wrote:
>>
>> On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
>> wrote:
>>>
>>> Hi,
>>>
>>> I got another threading question for the pros out there:
>>>
>>> In  my current application I am using QThread objects and
>>> QObject.moveToThread() to enable my GUI to download multiple files while
>>> updating progress bars in the main event loop. This is the respective
>>
>> As usual, the usual disclaimer: you do not need threads to do networking
>> or
>> file I/O. The combined overhead of the networking I/O and saving of the
>> files is
>> unlikely to overwhelm the event loop to the point that the progress bar
>> can't
>> update smoothly.
>>
>> I'm not saying impossible, but it's unlikely.
>>
>>> snippet of code:
>>>   self.worker = MyClass()
>>>   self.workerThread = QtCore.QThread()
>>>   self.worker.moveToThread(self.workerThread)
>>>
>>> The trouble is when the user wants to download multiple files at once.
>>> In my current implementation that all works fine and I see multiple
>>> progress bars do there thing.
>>> However, there are cases when I need to force the download threads to be
>>> synchronous. I had hoped that I can use QThreadPool with QThreads, but
>>> turns out I need QRunnables in this case, and those don't have the same
>>> signals as QThread.
>>
>> Why do you need to force them to be synchronous? And synchronous with
>> what?
>> With each other? Or do you mean sync() in the file saving?
>>
>> Finally, what does being synchronous have to do with signals?
>>
>>> So my question is:
>>> Is there a good way to use QThreads in a queue which is controlled by
>>> the main thread, or should I re-write my code and subclass QRunnable to
>>> add the signals I need (i.e. the ones that QThread has by default)?
>>
>> The whole point of QThread is that the code it runs is independent of
>> anything
>> else. Only the OS scheduler decides when it's time to run it or suspend
>> it.
>>
>>> In the latter case I guess I'd have to inherit from both QObject and
>>> QRunnable, is this ok?
>>
>> Right.
>>
>> But we still don't understand what you're trying to do. All I can tell you
>> is
>> that you don't need to do what you're trying to do, since you don't need
>> threads in the first place.
>>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads (Frank Rueter | OHUfx)

[Tim Iskander]

instead of re-architecting your threading model, could you just tweak the
downloader class to
take a list of files and then each one would be synchronous. multiple
concurrent downloads would each have a list of 1 file.
just a thought...

-- 
Tim Iskander
Senior Engineer
Critical Link LLC (315) 425-4-45 x271
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

Hi Thiago,

thanks for your quick reply. I will try and give some more context:
I use the python requests module inside my PySide app to post requests 
to a website. Some of those requests return a lot of data that I need to 
parse to be able to show progress, other requests are file downloads 
that I need progress bars for as they stream onto disk.
I had tried to not use threads and use QApplication.processEvents() for 
each data chunk downloaded, but that made the download about 4-5 times 
slower. Introducing threading made a huge difference.


My app can download a list of files at the same time. Depending on the 
situation and the user request, the list of files to be downloaded can 
happen asynchronously, in other situations they need to be downloaded 
one after the other.


>>All I can tell you is that you don't need to do what you're trying to 
do, since you don't need threads in the first place.
If I can avoid threads to do the above I would be more than happy to 
adjust and get rid of them again, but I haven't managed to find a 
non-threaded approach that doesn't slow down the download significantly.


Cheers,
frank

On 18/01/17 6:26 PM, Thiago Macieira wrote:

On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
wrote:

Hi,

I got another threading question for the pros out there:

In  my current application I am using QThread objects and
QObject.moveToThread() to enable my GUI to download multiple files while
updating progress bars in the main event loop. This is the respective

As usual, the usual disclaimer: you do not need threads to do networking or
file I/O. The combined overhead of the networking I/O and saving of the files is
unlikely to overwhelm the event loop to the point that the progress bar can't
update smoothly.

I'm not saying impossible, but it's unlikely.


snippet of code:
  self.worker = MyClass()
  self.workerThread = QtCore.QThread()
  self.worker.moveToThread(self.workerThread)

The trouble is when the user wants to download multiple files at once.
In my current implementation that all works fine and I see multiple
progress bars do there thing.
However, there are cases when I need to force the download threads to be
synchronous. I had hoped that I can use QThreadPool with QThreads, but
turns out I need QRunnables in this case, and those don't have the same
signals as QThread.

Why do you need to force them to be synchronous? And synchronous with what?
With each other? Or do you mean sync() in the file saving?

Finally, what does being synchronous have to do with signals?


So my question is:
Is there a good way to use QThreads in a queue which is controlled by
the main thread, or should I re-write my code and subclass QRunnable to
add the signals I need (i.e. the ones that QThread has by default)?

The whole point of QThread is that the code it runs is independent of anything
else. Only the OS scheduler decides when it's time to run it or suspend it.


In the latter case I guess I'd have to inherit from both QObject and
QRunnable, is this ok?

Right.

But we still don't understand what you're trying to do. All I can tell you is
that you don't need to do what you're trying to do, since you don't need
threads in the first place.



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QThreadPool functionality for QThreads

[Frank Rueter | OHUfx]

Hi,

I got another threading question for the pros out there:

In  my current application I am using QThread objects and 
QObject.moveToThread() to enable my GUI to download multiple files while 
updating progress bars in the main event loop. This is the respective 
snippet of code:

self.worker = MyClass()
self.workerThread = QtCore.QThread()
self.worker.moveToThread(self.workerThread)


The trouble is when the user wants to download multiple files at once. 
In my current implementation that all works fine and I see multiple 
progress bars do there thing.
However, there are cases when I need to force the download threads to be 
synchronous. I had hoped that I can use QThreadPool with QThreads, but 
turns out I need QRunnables in this case, and those don't have the same 
signals as QThread.

So my question is:
Is there a good way to use QThreads in a queue which is controlled by 
the main thread, or should I re-write my code and subclass QRunnable to 
add the signals I need (i.e. the ones that QThread has by default)?
In the latter case I guess I'd have to inherit from both QObject and 
QRunnable, is this ok?



Cheers,
frank



--
ohufxLogo 50x50  	*vfx compositing 
 | *workflow customisation and 
consulting * *


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest