if i only use Profiler should i import ddtrace.auto before gevent.monkey.patch_all?

[zdyj3170101136]

if i only use Profiler should i import ddtrace.auto before gevent.monkey.patch_all?

[zdyj3170101136]

and how should i verify that the Profiler work well with gevent?

could you please provide a small demo?

[P403n1x87]

Yes, when using any of the features of ddtrace, it is recommended that ddtrace.auto is imported as the very first thing when not using the ddtrace-run command, and especially when using gevent.

We have an example for the compatibility between ddtrace and gevent in our test suite that is specific to profiling https://github.com/Datadog/dd-trace-py/blob/aa32be7a6d17917199a7da041bb86f62310c7971/tests/profiling/simple_program_gevent.py. The typical sign of issues that can arise when not importing ddtrace.auto at the right time is the timeout of gevent workers, and/or SSL-related issues in network-based applications.

[zdyj3170101136]

from the gevent patch commit a665ffe#diff-35c795a5729666c71a99bc5dabeb4c30cb20608695d22719b73c0fd6701cb338

i saw it most do three things:

• let forksafe run correctly with gevent
• get correct thread name.
• let lock work well both with gevent and threading.

i wonder why we need a lock that prevent concurrency from a gevent coroutine and from a threading.Thread at the same time?
see a665ffe#diff-35c795a5729666c71a99bc5dabeb4c30cb20608695d22719b73c0fd6701cb338L84

[P403n1x87]

i wonder why we need a lock that prevent concurrency from a gevent coroutine and from a threading.Thread at the same time?

The linked commit is where the DoubleLock class (which I think is the locking mechanism described in the question) was removed, and that's because we no longer need this double locking with the current approach for the gevent support.