-
-
Notifications
You must be signed in to change notification settings - Fork 1
Diagnostics Interface #5
Copy link
Copy link
Open
Labels
domain: RustInvolves Rust code.Involves Rust code.priority: somedayIf you need this, please let me know!If you need this, please let me know!state: approvedApproved to proceed.Approved to proceed.type: featureBrand new functionality, features, pages, workflows, endpoints, etc.Brand new functionality, features, pages, workflows, endpoints, etc.work: emergentThe goal isn't known, but a plan exists.The goal isn't known, but a plan exists.
Description
Activity
Metadata
Metadata
Assignees
Labels
domain: RustInvolves Rust code.Involves Rust code.priority: somedayIf you need this, please let me know!If you need this, please let me know!state: approvedApproved to proceed.Approved to proceed.type: featureBrand new functionality, features, pages, workflows, endpoints, etc.Brand new functionality, features, pages, workflows, endpoints, etc.work: emergentThe goal isn't known, but a plan exists.The goal isn't known, but a plan exists.
Projects
- StatusShow more project fieldsReady
Is your feature request related to a problem? Please describe.
It can be helpful to visualise the current state of all (active-ish) signals at a given time in order to better understand a program, especially visually.
Describe the solution you'd like
The best way to solve this would likely be to add another trait that runtimes may implement to associate human-readable names with signals and retrieve diagnostic information. (Signals should not depend on this trait for their core functionality.) Visualising the dependency DAG formed by signals similarly to those rendered by e.g. Mono-Diagram would be very helpful, too.
Describe alternatives you've considered
It may be possible to surface this information in a way that's compatible with an existing profiler.
Additional context
-