Skip to content

Implement TracerClock and abstract away "now" #98

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

Merged
merged 9 commits into from
Mar 29, 2023

Conversation

ktoso
Copy link
Member

@ktoso ktoso commented Mar 23, 2023

Motivation:
we do not want to be bound to DispatchWallTime, but we cannot require Clock. We need to introduce a shim type TracerClockProtocol that in the future we'll be able to conform a "good Swift clock" to.

This removes any dependencies on dispatch and makes the Time source swappable. We also implement our own unix timestamp clock.

The core of the change is:
Screenshot 2023-03-23 at 22 53 37

resolves #71

WIll get to clean this up and make all versions work soon. At least locally confirmed swiftlang-5.7.0.123.8 worked fine

@ktoso ktoso requested review from slashmo and fabianfett March 23, 2023 13:54
@ktoso
Copy link
Member Author

ktoso commented Mar 28, 2023

Just need to get 5.6 done in the overloads maddness and we're done here 🥳

@ktoso ktoso force-pushed the wip-clock-no-time-like-the-present branch from 0746edd to 61cde0d Compare March 29, 2023 08:05
ktoso added 7 commits March 29, 2023 18:22
**Motivation:**
we do not want to be bound to DispatchWallTime, but we cannot require
Clock. We need to introduce a shim type TracerClockProtocol that in the
future we'll be able to conform a "good Swift clock" to.

This removes any dependencies on dispatch and makes the Time source
swappable. We also implement our own unix timestamp clock.
@ktoso ktoso force-pushed the wip-clock-no-time-like-the-present branch from 8b813dc to b869093 Compare March 29, 2023 09:25
@ktoso ktoso force-pushed the wip-clock-no-time-like-the-present branch from b869093 to 8b2be68 Compare March 29, 2023 09:30
Copy link
Member

@FranzBusch FranzBusch left a comment

Choose a reason for hiding this comment

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

Some small comments

@@ -154,17 +148,28 @@ public struct SpanEvent: Equatable {
public var attributes: SpanAttributes

/// The `DispatchWallTime` at which this event occurred.
public let time: DispatchWallTime
public let time: UInt64
Copy link
Member

Choose a reason for hiding this comment

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

Can we add some docs what this timestamp is e.g. millis since Epoch? Interestingly enough should we make this opaque or not?

Copy link
Member Author

Choose a reason for hiding this comment

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

Opaque is rather tricky what it would mean... Practically speaking we need timestamps, a tracer could decide it needs some specific way of those but by the end of the day it all ends up as ints I guess.

Making it all a type bound to Tracer is a huge mess type wise if we need to retain the 5.6 support :-\

function: String = #function,
file fileID: String = #fileID,
line: UInt = #line,
_ operation: (any Span) async throws -> T
Copy link
Member

Choose a reason for hiding this comment

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

Aren't we missing a @_inheritActorContext and @Sendable annotation here. Otherwise this could runs into warnings right?

actor Foo {
  var bar = 0 
  func foo() async {
    await withSpan {
      self.bar += 1
    }
  }
}

The downside of adding these annotations is that the story inside classes/structs is becoming worse because they don't have any actor context so the @Sendable constraint makes it impossible for them to access state even though the operation closure is run "inline".

In the end, we really need a productionized version of @_unsafeInheritExecutor. We are running into the same problem over in service-lifecycle.

Copy link
Member Author

@ktoso ktoso Mar 29, 2023

Choose a reason for hiding this comment

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

I checked and we don't get warnings for this 🤔

I think the function should NOT be sendable though

}

public protocol SwiftDistributedTracingInstantProtocol: Comparable, Hashable, Sendable {
// associatedtype Duration: SwiftDistributedTracingDurationProtocol
Copy link
Member

Choose a reason for hiding this comment

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

Can we remove this?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes thanks

public protocol TracerInstantProtocol: SwiftDistributedTracingInstantProtocol {
/// Representation of this instant as the number of milliseconds since UNIX Epoch (January 1st 1970)
@inlinable
var millisSinceEpoch: UInt64 { get }
Copy link
Member

Choose a reason for hiding this comment

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

Do we want to spell this out?

Suggested change
var millisSinceEpoch: UInt64 { get }
var millisecondsSinceEpoch: UInt64 { get }

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok :)

Comment on lines +106 to +107
let nowNanos = UInt64(ts.tv_sec) &* 1_000_000_000 &+ UInt64(ts.tv_nsec)
let nowMillis = UInt64(nowNanos / 1_000_000) // nanos to millis
Copy link
Member

Choose a reason for hiding this comment

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

I thought we were going to use a different method to calculate UTC time?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I had a whole complicated dance which... ended up at the same number ¯_(ツ)_/¯

Discussed with @Lukasa and we're unsure why Foundation does the extreme dance there; This is good enough for us. And we could support nanos even but for now I didn't

@ktoso
Copy link
Member Author

ktoso commented Mar 29, 2023

Thanks for the review @FranzBusch I'm going to merge so we can give this a round of testing

@ktoso ktoso merged commit a5b5160 into main Mar 29, 2023
@ktoso ktoso deleted the wip-clock-no-time-like-the-present branch March 29, 2023 10:44
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

Successfully merging this pull request may close these issues.

Adopt Clock in tracing APIs
2 participants