Repository navigation
Record the operator a thread is scheduling - #831
Merged
Merged
Conversation
Adds `scheduling::current`, a thread-local holding the global identifier of the operator whose `schedule` call is running. Code without a handle to the operator, such as a global allocator attributing allocations, reads it with `current::operator()`. Hosts claim an operator for work done on its behalf outside `schedule` with `current::enter`. The thread-local is const-initialized and has no destructor, so reading it from an allocator neither allocates nor reenters. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…lue's meaning Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
antiguru
marked this pull request as ready for review
October 29, 2026 19:56
Comment on lines
+13
to
+16
| //! The current operator is whoever is running, not whoever owns the data. An allocation made by | ||
| //! one operator and handed to another, such as a buffer pushed through `Pipeline`, is attributed | ||
| //! to the operator that made it. Work outside any operator, such as communication in | ||
| //! `Worker::step` and dataflow construction, has no current operator. |
Member
There was a problem hiding this comment.
Minor, but: this may be relevant for the allocator example, but it is not specific to this code or feature.
Member
Author
There was a problem hiding this comment.
Agreed, removed in 50a7f84. The docs keep only that work outside any operator has no current operator; the ownership caveat moved to the allocator consumer.
Posted by Claude Code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
timely::scheduling::current, a thread-local holding the global identifier of the operator whoseschedulecall is running, the same identifierScheduleEventreports.PerOperatorState::scheduleand the worker's dataflowWrapper::stepset it for the duration of the call, and guards restore the enclosing operator, so the innermost operator is current.The motivating use is attributing sampled heap allocations to dataflow operators from a global allocator. Logging can't serve this: events are buffered and arrive after the allocation, and the allocator has no handle to the worker. The thread-local is const-initialized and has no destructor, so reading it from an allocator neither allocates nor reenters.
current::enteris public so a host can charge work done on an operator's behalf outside itsschedulecall, for example trace maintenance or compaction, to that operator.The cost is one thread-local swap and restore per schedule. In a Materialize prototype with about 50k schedules per second the hook did not show up in a CPU profile. With it, 92% of the sampled live heap was attributed to an operator.
🤖 Generated with Claude Code