There's apparently a few places where we do not call ->finalize
or ->finish and leave dangling limiter slots occupied. I can't
reproduce this easily, so it's likely in error-handling paths.
I already made ->finalize idempotent when switching to awaitpid
since I wanted to rely entirely on DESTROY. However, DESTROY
doesn't always fire soon enough (and the client has already seen
a response), but using DESTROY as a fallback seems reasonable..
This does the minimum to ensure the limiter is freed up on
process exit, but ensuring a finish/finalize call always happens
is the goal.
---
lib/PublicInbox/Qspawn.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/PublicInbox/Qspawn.pm b/lib/PublicInbox/Qspawn.pm
index 02357dbf..78afe718 100644
--- a/lib/PublicInbox/Qspawn.pm
+++ b/lib/PublicInbox/Qspawn.pm
@@ -104,6 +104,8 @@ sub finalize ($) {
}
}
+sub DESTROY { finalize($_[0]) } # ->finalize is idempotent
+
sub waitpid_err { # callback for awaitpid
my (undef, $self) = @_; # $_[0]: pid
$self->{_err} = ''; # for defined check in ->finish
