You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Ruby 3.1 we introduced the Process._fork (see PR), which was targeted at the specific use case that we have in the library, where we need to keep track of fork() calls and properly handle state cleaning/flushing on dispatcher threads.
We should replace the complex logic for handling dispatcher threads in both the Aggregator and the BatchedSink with those hooks. If possible, create some kind of cross cutting module that uses some kind of Pub/Sub architecture to let the interested components know a fork happened.
Caveats
Note that since that is a feature from Ruby 3.1 we would have to drop support for Ruby < 3.1. But that should not be a problem since, at the time of this writing, 3.0 is EOL (April 2024) and 3.4 is on the verge of going GA.
Summary
In Ruby 3.1 we introduced the
Process._fork
(see PR), which was targeted at the specific use case that we have in the library, where we need to keep track offork()
calls and properly handle state cleaning/flushing on dispatcher threads.We should replace the complex logic for handling dispatcher threads in both the Aggregator and the BatchedSink with those hooks. If possible, create some kind of cross cutting module that uses some kind of Pub/Sub architecture to let the interested components know a fork happened.
Caveats
Note that since that is a feature from Ruby 3.1 we would have to drop support for Ruby < 3.1. But that should not be a problem since, at the time of this writing, 3.0 is EOL (April 2024) and 3.4 is on the verge of going GA.
Relates to #384
The text was updated successfully, but these errors were encountered: