[OE-core] [PATCHv2 2/2] rpm: run binary package generation via thread pools
Alexander Kanavin
alexander.kanavin at linux.intel.com
Fri Jun 9 09:02:22 UTC 2017
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
More information about the Openembedded-core
mailing list