This is a follow-up PR to #10267, and addresses #10267 (comment).
I am adding extra work for @jnewbery in #12755 here -- maybe I should just rebase on top of that, but not sure what the appropriate approach is here.
This is a follow-up PR to #10267, and addresses #10267 (comment).
I am adding extra work for @jnewbery in #12755 here -- maybe I should just rebase on top of that, but not sure what the appropriate approach is here.
I am adding extra work for @jnewbery in #12755 here -- maybe I should just rebase on top of that, but not sure what the appropriate approach is here.
I (personally) prefer if PRs are more or less independent. As having a web of dependencies between them makes it even harder to keep track of them. On the other hand, #10267 is now in, and #12755 should probably be next.
utACK 6f10309.
BTW couldn't cs_args be locked the whole time?
Since -includeconf cannot be used recursively, the user would not see feedback that an -includeconf
in an -includeconf'd file was silently ignored.
Rebased.
@promag Is it better locking the whole time?
I don't know what the potential races here are, but If everything else is the same, keeping the lock closely around the section where it is needed is preferable. Also: calls such as GetArgs take their own lock, so already holding it is sloppy.
ReadConfigFiles should be an atomic operation right?
As far as I know we don't really make any assumptions in that regard right now, but in sane API design I think that makes sense.
I can try moving the lock to the top of the method and remove it elsewhere. I am concerned it may cause deadlocks though.
ba5b9fc
@kallewoof I think it's great to change that but in a different PR. Commit 2352aa9f is enough here. Sorry for asking here!
Yeah doesn't seem as simple as I hoped. Dropping ba5b9fc.
utACK 2352aa9f3681fbcfb89a1910d9c5529dac9ca2e9