cancel slot not getting called with QtConcurrent::run()

[prasad_N]

If suppose I need to read 5 lak rows of data from DB, I am starting 5 threads so that each thread read 1 lak rows, at the end I will merge the result.
The thing is that reading records is from third party function so I do not have control over it(I don't know what is happening inside, how much time will take, I cant not put any bool variable inside it to stop at particular condition ...).

[anda_skoa]

So the third party API only allows you to read 1 lak rows, no smaller amount?

I.e. you can't read 50 times 0.1 lak rows?

Cheers,
_

[prasad_N]

So the third party API only allows you to read 1 lak rows, no smaller amount?

I can read any number, just I need to pass boundaries (start row & end row Indexes).

I.e. you can't read 50 times 0.1 lak rows?

I can, But what is the use of this approach reading 50 times 0.1 lak rows? (Sorry I may not get your logic)

Note: We did some experiment and find out that more that 8 threads are slowing down the performance on my machines.
So we are running max 8 threads to to read entire data.

[anda_skoa]

I can read any number, just I need to pass boundaries (start row & end row Indexes).

Then you can split the work into smaller steps, which you said you could not (comment #7)

I can, But what is the use of this approach reading 50 times 0.1 lak rows? (Sorry I may not get your logic)

Smaller units of work take less time, waiting for such a smaller amount of time on cancel makes the program react to cancel faster.

Note: We did some experiment and find out that more that 8 threads are slowing down the performance on my machines.
So we are running max 8 threads to to read entire data.

I already thought that 5 threads are pretty optimistic, but I am not suggesting increasing the number of threads at all.

Cheers,
_

[prasad_N]

Then you can split the work into smaller steps, which you said you could not (comment #7)_

yes, it could have been I don't want instead I cann't :-)

Smaller units of work take less time, waiting for such a smaller amount of time on cancel makes the program react to cancel faster._

I will try this and get back with the result, I need to check how much time it will take to read entire DB (My main aim is to minimize reading time).

I already thought that 5 threads are pretty optimistic, but I am not suggesting increasing the number of threads at all._

I am working on SLES11 server(high end machine), more that 5 threads might works in my case.