-
-
Notifications
You must be signed in to change notification settings - Fork 1
Io capture #46
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
base: errors-and-logging
Are you sure you want to change the base?
Io capture #46
Conversation
design-docs/capture-output-implementation-plan.md: Signed-off-by: Tzanko Matev <[email protected]>
codetracer-python-recorder/src/ffi.rs: codetracer-python-recorder/src/runtime/frame_inspector.rs: codetracer-python-recorder/src/runtime/mod.rs: codetracer-python-recorder/src/runtime/thread_snapshots.rs: codetracer-python-recorder/src/runtime/trace_writer_host.rs: codetracer-python-recorder/src/session.rs: design-docs/capture-output-implementation-plan.status.md: Signed-off-by: Tzanko Matev <[email protected]>
Coverage SummaryRust (lines)
Python (statements)
Generated automatically via |
very impressive: but a radical approach: can't we somehow monkey patch the internal place/code that produces the writes? maybe this approach covers more fully/cleanly some cases, but it still seems a bit heavier on the other hand: not critical, maybe for the future, but to check the current approach: what about file/other kind of events(in the future: network and others?) wouldn't we need something different for them, or would a similar approach be possible |
I don't think that we can monkeypatch. We would need to detect all calls to C functions which deal with IO. But what if they are not from the standard library? For example our Rust module can produce logging statements which such an approach cannot handle. Here we just redirect the in, out and error streams and we capture everything that we see. It is possible to be even more ambitious on Linux using BPF. We can hook to the read and write syscalls. This means that we can map IO to which thread caused it. I am working on a prototype POC to test this approach as well. |
ok, i have to try to understand it in more detail: will try to see/or ask next week; bpf sounds interesting, maybe it can help with the general case of IO events, but still not sure if we can match them to the actual step in the general case(and here) |
No description provided.