Potential deadlock in batch span processor and periodic metric reader after puma fork child processes

[xuan-cao-swi]

In Rails applications using Puma, Puma forks child processes when running in clustered mode. Components like BatchSpanProcessor and PeriodicMetricReader can restart their threads after forking, thanks to mechanisms like after_fork and reset_on_fork. However, I’ve noticed that the mutexes in these classes are not properly cleaned up (e.g., unlocked or reinitialized) after a fork. Since mutex objects and their states are copied to the child process, a locked mutex in the parent remains locked in the child. Attempting to lock it again in the child can cause a deadlock.

Although I haven’t seen reports of this issue occurring in practice, it’s something developers should be aware of when working with Puma and mutexes

[xuan-cao-swi]

After did more research about thread.c from ruby, it seems like ruby interpreter will intentionally unlock all mutex after fork; so the problem probably is well-handled by ruby.

Reference:
https://bugs.ruby-lang.org/issues/8433
https://bugs.ruby-lang.org/issues/10443
ruby/ruby@57b8687#diff-161b2a279f4c67a1ab075a7890ecf6f3f1d483d910910fa52b3715e25cfdcbd7

[cheempz]

Awesome, thanks for looking into this!