[go: nahoru, domu]

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

Span linking #21

Open
yaitskov opened this issue May 23, 2020 · 1 comment
Open

Span linking #21

yaitskov opened this issue May 23, 2020 · 1 comment

Comments

@yaitskov
Copy link

I don't understand how nested span is linked to its parent.

withSpan doesn't have argument for parent span in flight id.
I see eventlog parser reconstructs structure through Event Cap number.
What is that? Offline thread id substitute?

if withSpan doesn't need parent span in flight id then why all other method need them?
if eventlog answers question any time from what thread user message comes and
what is parent thread for new thread then exposing span in flight to an application developer looks redundant.

@yaitskov
Copy link
Author

Event cap is CPU core id or os thread id.

GHC eventlog format is very power full. It allows to reconstruct the whole thread of process.
SpanInFlight could useful for developer api only in case of forking.
Developer has to have a way to propagate trace id to child thread in runtime, cause the child thread could make HTTP calls and has to know trace id at moment of calling not at parsing time.
OpenTelemetry.
Though SpanInFlight is not enough. Trace id should be stored in accessible way.

I think OpenTelemtery need help from GHC RTS in form of ThreadProtected abstraction (mix of thread local and global variable):
any thread can bind arbitrary value with itself and that value should propagate automatically to all child threads direct or indirect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant