Is your feature request related to a problem? Please describe.

In #3015, we identified an issue where dd-trace-rb background threads calling getaddrinfo at the same time as a Ruby application is trying to fork (e.g. Resque) could cause the underlying C library to get stuck in an inconsistent state, leading to deadlocks.

We documented in https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/ruby/#resque-workers-hang-on-exit our recommended workaround for this issue.

Describe the goal of the feature

Recently in #3015 (comment) the issue came up of protecting these problematic calls with a lock, similar to https://bugs.ruby-lang.org/issues/20590 / ruby/ruby#10864 .

Such a mechanism should make dd-trace-rb work out-of-the-box in every situation, avoiding the problematic case.

It looks like Ruby 3.4 might have such a feature built-in, but I do think it makes sense to have our own as:

• We'll be supporting customers with Ruby < 3.4 for a looong time still
• Any calls done directly via e.g. libdatadog wouldn't be protected by the Ruby VM mechanism

Describe alternatives you've considered

There's a longer discussion in #3015 but the other alternatives are closer to "workarounds" than actual solutions to the underlying problem.

Additional context

N/A

How does datadog help you?

N/A