Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor execution_context to use RuntimeContext #573

Merged
merged 3 commits into from
Mar 22, 2019
Merged

Conversation

reyang
Copy link
Contributor

@reyang reyang commented Mar 21, 2019

This is part of the #564 effort.

Today we have trace/execution_context, tags/execution_context and stats/executino_context built on top of Thread-local Storage, which I plan to refactor.

This PR simply refactored execution_context from Thread-local Storage to RuntimeContext (introduced in #566).

@reyang reyang requested review from c24t, songy23 and a team as code owners March 21, 2019 21:52
delattr(_thread_local, 'tracer')
_attrs_slot.clear()
_current_span_slot.clear()
_tracer_slot.clear()


def clear():
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@c24t I think having a test-only method exposed publicly is evil. I plan to remove it or make it "private". Please let me know your thoughts.

BTW, _thread_local.__dict__.clear() will remove Thread-local storage introduced by other components (e.g. stats), not sure if this is intended. @liyanhui1228 might have some background on this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this is a cardinal sin. We may be able to remove this entirely soon -- if we stop storing the tracer and measure to view map in the context and control span and tag lifetimes with context managers then hopefully tests won't pollute the context (and should be able to run in parallel!).

@reyang reyang changed the title Migrate trace/execution_context to RuntimeContext Refactor execution_context to use RuntimeContext Mar 21, 2019
attrs = RuntimeContext.attrs
current_span = RuntimeContext.current_span
tracer = RuntimeContext.tracer
return tracer, current_span, attrs


def set_opencensus_full_context(tracer, span, attrs):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This set_opencensus_full_context probably should be removed (in another PR):

  1. It is not the "full context" as it doesn't cover tags.
  2. RuntimeContext.apply provides the intended functionality, which can be used by propagating context to explicit threads.

Copy link
Member

@c24t c24t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments about future changes to the context, but nothing to act on in this PR. LGTM!

delattr(_thread_local, 'tracer')
_attrs_slot.clear()
_current_span_slot.clear()
_tracer_slot.clear()


def clear():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this is a cardinal sin. We may be able to remove this entirely soon -- if we stop storing the tracer and measure to view map in the context and control span and tag lifetimes with context managers then hopefully tests won't pollute the context (and should be able to run in parallel!).


_thread_local = threading.local()
_measure_to_view_map_slot = RuntimeContext.register_slot(
'measure_to_view_map',
Copy link
Member

@c24t c24t Mar 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would only make sense to store measure_to_view_map in the context if we wanted to e.g. register views in one thread (or async coroutine) and not another. If we can stop storing this in the context we can lose this module completely. FWIW other language clients don't have a stats execution context, and java uses a singleton for the measure to view map.

Definitely out of scope for this PR, just something to keep in mind as we're formalizing the context API.



def set_current_tag_map(current_tag_map):
setattr(_thread_local, 'current_tag_map', current_tag_map)
RuntimeContext.current_tag_map = current_tag_map
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually get/set needs to be replaced with a context manager that restores the old tag map on exit. This would also let us lose clear.

# If there is no attrs, initialize it to empty dict.
attrs = getattr(_thread_local, 'attrs', {})

attrs = RuntimeContext.attrs.copy()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting attrs on the context directly instead of the current span might be unique to the python client. It looks like this is used to:

  1. store the host blacklist in the flask and django integrations
  2. store the current span ID in the httplib integration
  3. store the request object in the django integration

(1) seems like it could be static config instead, (2) seems like it could use the current span, and (3) seems to be used to get the trace headers from the request object, which we might be able to do at request time instead.

Hopefully we can remove this too, and only set attrs on the current context.

@reyang reyang merged commit 928c704 into experimental Mar 22, 2019
reyang added a commit that referenced this pull request Mar 23, 2019
Migrate execution_context to RuntimeContext
@reyang reyang deleted the runtimecontext branch March 23, 2019 04:59
reyang added a commit that referenced this pull request Mar 29, 2019
Migrate execution_context to RuntimeContext
reyang added a commit that referenced this pull request Apr 1, 2019
Migrate execution_context to RuntimeContext
@reyang reyang mentioned this pull request May 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants