On 20/01/21 17:26, Max Reitz wrote:
Now, this all seems obvious to me, but I’m wondering... If
coroutine-sigaltstack really couldn’t create coroutines concurrently,
why wouldn’t we have noticed before? I mean, this new backup case
is kind of a stress test, yes, but surely we would have seen the
problem already, right? That’s why I’m not sure whether my analysis
is correct.
Probably the BQL was hiding the issue?
Anyway, I’ve attached a patch that wraps the whole
SIGUSR2 handling section in a mutex, and that makes 256 pass reliably
with Vladimir’s async backup series. Besides being unsure whether
the problem is really in coroutine-sigaltstack, I also don’t know
whether getting out the big guns and wrapping everything in the mutex
is the best solution. So, it’s an RFC, I guess.
I think that's fine. The coroutine pool will hide scalability issues.
Paolo
