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 ferrisetw 0.1, UserTrace::enable should be used to add a Provider to a trace. But, IIRC, this has no effect on a trace that has started already (the provider is pushed to a list, but EnableTraceEx2 is not called on this new trace).
To fix this problem, the next_major_version branch reworks this enable function and forces to define all Providers before the trace is started.
But the Windows API allows enabling/disabling providers when the trace is running (using EnableTraceEx2, so this could be worth supporting this in ferrisetw
The text was updated successfully, but these errors were encountered:
Note: trace_callback_thunk is currently safe (memory-safety-wise) because CallbackData is not mutated when a trace is running.
When resolving this issue, we will mutate the list of providers (which is a member of CallbackData) in one thread while another thread may run a callback (and read this list of Providers). We must synchrionize it in some way and make sure the Provider cannot be removed during a callback (wrapping the Vec<Provider> in a Mutex may or may not be sufficient, this must be carefully checked)
In ferrisetw 0.1,
UserTrace::enable
should be used to add a Provider to a trace. But, IIRC, this has no effect on a trace that has started already (the provider is pushed to a list, butEnableTraceEx2
is not called on this new trace).To fix this problem, the
next_major_version
branch reworks thisenable
function and forces to define all Providers before the trace is started.But the Windows API allows enabling/disabling providers when the trace is running (using
EnableTraceEx2
, so this could be worth supporting this in ferrisetwThe text was updated successfully, but these errors were encountered: