Make the threadpool honour the int argument for number of elements to process

We have two cases, the original issue with a single thread with more than 2^31 elements and the less likely case when more threads also exceed 2^31 elements per thread. The strategy is simple, honour the contract of the map function and only pass in 2^31 elements per call by restricting the chunks to INT_MAX.

Fixes #727 (closed)

added bug cleanup labels

mentioned in issue #727 (closed)

added 1 commit

• d3bda985 - Don't limit auto chunk size to (int) handle > INT_MAX instead of overflowing

Compare with previous version

added 1 commit

• 650de88e - Formatting and remove debug

Compare with previous version

assigned to @matthieu and unassigned @pdraper

unmarked as a Work In Progress

All looks good to me now. If you want to play outside of the running the code on a volume here is my test threadpool:

threadpool-loop.c

Just change tp.num_threads, N and chunk in main().

changed the description

Obviously no hurry for this!

I think jenkins wasn't happy building this with gcc but I lost the email...

Sorry, yes saw that, it is some comparison of signed and unsigned types it was not happy with. Strangely later GCCs didn't complain. I'll fix that up.

added 1 commit

• 1ae37365 - Squash an unsigned comparison warning

Compare with previous version

Pushed a fix for the Jenkins issue.

That all seems fine by me. It also does not modify the behaviour in all the normal cases so good to go from my side.

merged

mentioned in commit 830d1f35