Fix for the rand_r() call from within a threadpool

@nnrw56 do you foresee any issues with this ? It runs the test-case that previously crashed.

That passes all the tests and prevents the crash @dc-arri1 reported (#355 (closed)). Now the question is a matter of style. Are we happy that the threadpool infrastructure becomes heavier ?

I don't really like it

What bothers me is that the whole threadpool thing should be independent of anything else. Because, conceptually at least, it is.

I'd much rather make a "fake" threadpool mapper function that sets this value and sits at a barrier (to make sure each thread in the threadpool gets a chunk), or even using some completely different approach, e.g. setting the seed to the pointer of the previous task or whatever...

So the issue is the call to rand_r() at the enqueing time for the tasks that don't have an obvious owner. How random does this have to be ? Can we live with something as stupid as getticks() % nr_queues and not bother with this pointer for the threadpool any more ?

I think that's the winning idea (using getticks, assuming the resulting value does not always end in zero or some power of two). Let's do that!

It has to be sufficiently random as to not always choose the same queue or the same subset of queues, no more and no less

See !411 (merged).

Implemented !411 (merged) instead.

Status changed to closed