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 support for attaching profiler to a PID (Linux only). #18

Merged
merged 3 commits into from
Jan 28, 2023

Conversation

ishitatsuyuki
Copy link
Contributor

This adds support for attaching to a PID by samply record -p 12345.

I only implemented (and feature flagged) this for Linux, since the attaching story seems more complicated on the macOS side.

-p will be used for the newly added --pid option.

Unfortunately this is a breaking change, but this allows the command line to be
consistent with perf.
Previously the profiler only terminated on process exit, but with PID attach
we need to stop it on user request. Allow passing-in an AtomicBool as a stop
flag.
For now, support this for Linux only since on macOS hooking stuff complicates
attaching.
Copy link
Owner

@mstange mstange left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent, thanks! I'll merge this and then fix the macOS build. I should probably set up some macOS CI.

Comment on lines +90 to +98
// When the first Ctrl+C is received, stop recording.
// The server launches after the recording finishes. On the second Ctrl+C, terminate the server.
let stop = Arc::new(AtomicBool::new(false));
#[cfg(unix)]
signal_hook::flag::register_conditional_default(signal_hook::consts::SIGINT, stop.clone())
.expect("cannot register signal handler");
#[cfg(unix)]
signal_hook::flag::register(signal_hook::consts::SIGINT, stop.clone())
.expect("cannot register signal handler");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've understood how this works, but it feels a bit non-obvious. It looks like register_conditional_default uses the AtomicBool as an input, whereas register uses it as an output. So on the first Ctrl+C, the first signal handler reads false and doesn't act, and the second signal handler writes true. Then on the second Ctrl+C, the first signal handler reads true and terminates. So the order of setting these handlers also matters.

I'll land this as-is, but I'm open for suggestions to make this easier to read.

@mstange mstange merged commit b6e300b into mstange:main Jan 28, 2023
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.

2 participants