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

Add a mock clock #17

Closed
schomatis opened this issue Jun 28, 2022 · 6 comments · Fixed by #20
Closed

Add a mock clock #17

schomatis opened this issue Jun 28, 2022 · 6 comments · Fixed by #20

Comments

@schomatis
Copy link

Context: libp2p/go-libp2p-core#267

It seems all Meters use a single globalSweeper running on the Go clock. I'm not sure how to go about this. For example:

  • Should each Meter have its own sweeper now (with its own mock/Go clock)?
  • Should we still rely on the globalSweeper but somehow have it track individual clocks (either in another structure like meters []*Meter or inside the Meters themselves)?

@Stebalien help (cc @marten-seemann)

@Stebalien
Copy link
Member

So, I created this library because metrics kept showing up in performance profiles.

  • Each meter should not have a sweeper, that would kill performance.
  • We can't have individual clocks (performance, complexity, size).

The best we could do would be to have a global clock and mock it via an environment variable (on init).

@marten-seemann
Copy link
Contributor

The best we could do would be to have a global clock and mock it via an environment variable (on init).

Not sure how you'd inject a clock via an environment variable, the caller needs to be able to control the (mock) clock.

We could introduce a SetClock(clock) function.

The interesting thing here is that once a sweeper is started, it can't be stopped. That means we can only single mock clock for all test cases. I don't expect this to be a problem though, after all, the tests work right now using a single clock.

@Stebalien
Copy link
Member

Not sure how you'd inject a clock via an environment variable, the caller needs to be able to control the (mock) clock.

Uh, sorry, not environment variable. Global variable.

We could introduce a SetClock(clock) function.

That also works, but it would likely still be a global.

@schomatis
Copy link
Author

Thanks for the input. I'm going then (unless someone says otherwise) with the global SetClock API meant to be called only once and before registering (using) any meter (leveraging the sweepOnce mechanism). It's on the test to inject the mock clock before using meters. (I'm assuming that separate tests have separate global/static contexts and hence separate sweepers.)

@schomatis
Copy link
Author

#18

@schomatis
Copy link
Author

(I'm assuming that separate tests have separate global/static contexts and hence separate sweepers.)

@marten-seemann @Stebalien We're sharing the global sweeper across tests so the above isn't correct and I'll need some advice on how to proceed.

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