Re: [PATCHv2 2/2] rpm: run binary package generation via thread pools

[Alexander Kanavin <alexander.kanavin@linux.intel.com>]

On 06/08/2017 11:29 PM, Mark Hatle wrote:
> Assuming that moving the call earlier (like you did) works, and the static
> values are retrievable by the function.  You could have fixed this with the
> snipped below (without storing the values).  This would simplify the patch.
>
> (If there is something in the way the threads work with openmp that makes the
> static variable not transfer from the main execution thread to the children
> threads -- that is a different issue and should be stated in the commit.)

Ah, now I get you. You are saying that if these functions are executed 
once at the start to pre-populate the static data, then they 
subsequently become thread-safe. Unfortunately this is not the case: I 
have no idea why this happens, as they would only read static data, but 
when I did that (in the first iteration of the patch which used nspr 
instead of openmp), there was a very rare, but still happening data 
corruption issue. There was no explicit first call, but the first 
package was built ahead of others (for other reasons, and it still is), 
and that's where the first call happened.

Then I commented out the calls, and the data corruption disappeared. 
Then I rewrote the function to eliminate the static data, and it's still 
working as expected. Weird! I don't want to spend any more time on this 
though.

Then there's my other point: use of static data makes it harder to 
reason about code. You need to take into account not only the function 
inputs, but also the history of function calls up to the current 
execution point. Static data is really a 70s C relic from before threads 
were invented.

Alex