Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements a new tracing support for uvloop adding the pair methods
start_tracing
andstop_tracing
that allows the user to start orstop the tracing. The user must provide a valid
uvloop.tracing.Tracer
implementation that would be used internally by uvloop to create spans,
each span must also meet the
uvloop.tracing.Span
class contract.This POC only implements the creation of spans during underlying calls
to the
getaddrinfo
function.This POC relates to the conversation in #163.
What is missing/What is pending to discuss:
MetricsSpan
,CounterSpan
andTimingSpan
controversial, this PR only implements a generic Span that is a timing one.uvloop.tracing.Tracer.current_span
needs to be adapted to avoid race conditions, when a span is created the "global" attribute is overwritten. Most likelycurrent_span
will end up as another context variable.Agreement of an almost final draft of the
start_tracing
entry point, right now the implementation hides theTracedContext
, so making it usable only internally by uvloop. I'm wondering if we must make it public providing to the user a way of creating spans in his code, so becoming the way of traceasynciouvloop code.Current implementation implicitly wires the Tracer context using the parent span, so for example when internally a new span is created using the
TracedContext.start_span
under the hood the parent span is passed to theTracer.create_span
, so allowing to the tracer to fetch some context information from this, also allowing make the new span child of the parent one. Should we reconsider this with a more explicit interface?Support for other spans within uvloop. But before doing this, we would need a kind of agreement of behind what circumstances the spans are created. A good example is the
create_connection
loop function, would feel comfortable with something like this:That it would mean that when there is no tracing enabled it will create a noop span, the benefits of this global wrapping is making the code cleaner and easier to maintain but the drawbacks are quite clear.
Also worth mentioning that going to a pattern that uses a global context would mean that we will be creating a span when indeed in some failure scenarios we connected to nothing and without yielding the loop.