-
Notifications
You must be signed in to change notification settings - Fork 140
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
Implement span_begin
and span_end
syscalls
#1816
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(initial review, more coming)
/// CID of the currently executing method's code. | ||
pub code: Cid, | ||
/// Number of the currently executing method. | ||
pub method: MethodNum, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- For the code CID, I'm adding a special event when we invoke an actor so we shouldn't need it here (PR WIP).
- With the method number, we should be able to derive that from the current
Call
.
/// The ID of the span that is ending. | ||
pub id: SpanId, | ||
/// The timestamp when this event ocurred, in nanoseconds. | ||
pub timestamp: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if, instead, we recorded a timestamp every time we entered/exited wasm? I.e.:
InvokeActor(cid, timestamp)
ExitActor(timestamp)
BeginSyscall(module, function, timestamp)
EndSyscall(timestamp)
This would also help with gas timing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make sure I understand correctly: would you like to do this instead of the span functionality, or would you like to do this as well as the span functionality?
I believe InvokeActor
and ExitActor
are equivalent to what we have today with Call
, CallReturn
, and CallError
.
Just for the record, I think that it would be useful to include the timestamp on every event. I think a change like this deserves a separate issue/PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, regarding your previous comment:
For the code CID, I'm adding a special event when we invoke an actor so we shouldn't need it here (PR WIP).
are you already adding InvokeActor
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make sure I understand correctly: would you like to do this instead of the span functionality, or would you like to do this as well as the span functionality?
In addition to spans. The idea is to split "spans" from "timestamps".
But you're right, doing it in a second PR makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you already adding InvokeActor?
@fridrik01 is likely going to do it in a few days as he'll need it for some tracing work he's doing in lotus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick review of the PR and implementation looks fine to me but lets wait on Steb's further comments
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #1816 +/- ##
===========================================
- Coverage 75.32% 54.51% -20.81%
===========================================
Files 149 112 -37
Lines 14553 9549 -5004
===========================================
- Hits 10962 5206 -5756
- Misses 3591 4343 +752
|
Part of #1566. Implements new syscalls for beginning and ending spans, and exposes them through the SDK. Adds new execution events for spans. Implements a new
TraceClock
abstraction to obtain nanosecond timestamps from theMachine
, which can later be used to add timestamps to allExecutionEvent
s for tracing.Tests the added functionality in an integration test.
What's not included in this PR:
I felt like the PR was already quite large, so I decided to leave these for separate PRs.