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: pass now to qlog #2212

Closed
wants to merge 1 commit into from
Closed

refactor: pass now to qlog #2212

wants to merge 1 commit into from

Conversation

mxinden
Copy link
Collaborator

@mxinden mxinden commented Nov 1, 2024

Instead of using QLogStream::add_event_data_now, which internally calls std::time::Instant::now(), pass now to
QLogStream::add_event_data_with_instant.

This would close #2211. That said, given that this change is very noisy, passing now across all layers and adding now to many of our public APIs (see neqo-bin/src for examples), I don't think it is worth it.

Let me know if you think otherwise.

Alternative: We could only do this change in neqo-transport, having all neqo-http3 functions calling neqo-transport functions with a fresh std::time::Instant::now(). That would give us proper qlogs when using test_fixtures::Simulator as that is only concerned with neqo-transport and that would reduce the noise. Downside, additional complexity, as the problem itself is only half fixed, i.e. in neqo-transport but not neqo-http3.

Instead of using `QLogStream::add_event_data_now`, which internally calls
`std::time::Instant::now()`, pass `now to
`QLogStream::add_event_data_with_instant`.
Copy link

github-actions bot commented Nov 1, 2024

Failed Interop Tests

QUIC Interop Runner, client vs. server

neqo-latest as client

neqo-latest as server

All results

Succeeded Interop Tests

QUIC Interop Runner, client vs. server

neqo-latest as client

neqo-latest as server

Unsupported Interop Tests

QUIC Interop Runner, client vs. server

neqo-latest as client

neqo-latest as server

@larseggert
Copy link
Collaborator

Probably a stupid idea, but can we make now a thread-local atomic that is written to when time is updated via our public API and otherwise only read everywhere?

@mxinden
Copy link
Collaborator Author

mxinden commented Nov 6, 2024

Probably a stupid idea, but can we make now a thread-local atomic that is written to when time is updated via our public API and otherwise only read everywhere?

We could use a thread-local atomic.

That said, I think the current approach on main, carrying now explicitly from function to function, is better. In my eyes, the fact that Neqo does have little to no side-effects (e.g. not accessing "global" thread local variables) is a strong feature, enabling easy debugging. In addition, while Neqo is generally single threaded, even here, reasoning about thread local state adds a lot of complexity.

I am reluctant to give up the above properties for #2211 alone. Instead of this pull request, or a thread local variable, I suggest we go with #2216.

@mxinden
Copy link
Collaborator Author

mxinden commented Nov 6, 2024

Closing here in favor of #2216.

@mxinden mxinden closed this Nov 6, 2024
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.

test: use provided (simulated) time in qlogs
2 participants