fix(task): forward signals to spawned sub-processes on unix #27141
Conversation
| kill_signal, | ||
| ), | ||
| ) | ||
| .await |
There was a problem hiding this comment.
What's done in this PR is the signal listening is setup at a high level and a KillSignal from deno_task_shell is piped through all the code into the task runner. Then when a signal is received it's sent along the KillSignal (which is kind of like a CancellationToken, but for sending signals).
runtime/ops/signal.rs
Outdated
There was a problem hiding this comment.
Moved to runtime/signal.rs
| ))] | ||
| #[derive(Debug, thiserror::Error)] | ||
| #[error("Invalid signal: {0}")] | ||
| pub struct InvalidSignalIntError(pub libc::c_int); |
There was a problem hiding this comment.
Everything is the same in this file except these new errors and it adds a SIGNAL_NUMS array for getting a list of signals that the operating system can listen to.
| let token = token.child_token(); | ||
| let droppable_token = DroppableToken(token.clone()); | ||
| let droppable_token = token.clone().drop_guard(); |
There was a problem hiding this comment.
Is this change related to "deno task"?
There was a problem hiding this comment.
I think it's ok. It's related to using drop_guards() everywhere now. I was going to refactor out this code for reuse and then found it was built-in.
| async fn listen_ctrl_c(kill_signal: KillSignal) { | ||
| while let Ok(()) = tokio::signal::ctrl_c().await { | ||
| kill_signal.send(deno_task_shell::SignalKind::SIGINT) | ||
| } | ||
| } |
There was a problem hiding this comment.
IIRC once you install Tokio signal, then it's process wide - ie. once installed it can't be uninstalled - this might lead to problems when lifecycle scripts are executed in deno run - please check if Ctrl + C works correctly to stop the process, after lifecycle script is run.
There was a problem hiding this comment.
Oh yeah, we probably shouldn't do this for lifecycle scripts.
Closes #18445