实现进程的停止与继续

[TomGoh]

目前，StarryOS 中进程存在两个状态，Running 与 Zombie，并且尚未支持通过 SIGSTOP 与 SIGCONT 进行动态的停止与继续。这里希望通过借助已经存在的信号基础设施 starry-signal 与 PollSet 等异步机制实现相关功能，为后续支持更完善的 waitpid 乃至 ptrace 提供基础。

这里拟定了三个仍处在 Draft 阶段的 PR，希望能够提供一个可靠的解决方案。

starry-process

首先，是关于 starry-process 的 PR：Starry-OS/starry-process#5

这个 PR 中主要增加了一个状态管理的标志位，包括 RUNNING, STOPPED, 和 ZOMBIE 三个状态，并且围绕这三个状态设置了 is_[state] 的状态判断函数与 transition_to_[state] 的状态转换函数，除此之外没有更改。之所以添加这三个状态是为了更好的向内核中进程管理提供接口，辅助更加上层的实际执行进程状态切换的 do_stop 与 do_continue 的实现。

starry-signal

然后，是关于 starry-signal 的 PR：Starry-OS/starry-signal#6

在这个 PR 中，首先针对就绪信号队列 pending.rs 进行了功能的扩充，提供了判断当前队列中是否存在某一信号的 has_signal 函数与从队列中移除某一个具体信号的函数 remove_signal。基于此，分别针对进程级别信号队列和线程级别信号队列进行功能扩充，添加进程和线程级别的 has_signal 判断函数，remove_signal 移除某一信号的函数和更加细化的 flush_stop_signals 移除所有可能导致进程停止的信号的函数。之所以进行这部分的更改是为了满足 POSIX 标准中的要求：

When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process or thread, all pending SIGCONT signals for that process or any of the threads within that process shall be discarded. Conversely, when SIGCONT is generated for a process or thread, all pending stop signals for that process or any of the threads within that process shall be discarded.

使得更上层的内核的进程管理能够根据收到的信号来处理队列中就绪但仍未处理的其他信号。

在原有的 starry-signal 中，如果一个线程/进程

• a. 阻塞（block）了 SIGCONT
• b. 在设置信号处理的 sigaction 的时候设置为忽略（ignore）了 SIGCONT

那么在该线程所在的进程被停止后， SIGCONT 信号将

• 在负责信号传送的 send_signal 函数中直接被丢弃

• 在被 handle_signal 过滤掉从而无法被返回处理，进程不能正常继续，违背了 POSIX 标准的要求：

When SIGCONT is generated for a process that is stopped, the process shall be continued, even if the SIGCONT signal is ignored by the process or is blocked by all threads within the process and there are no threads in a call to a sigwait( ) function selecting SIGCONT.

因此需要针对 SIGCONT 进行额外处理。

针对 SIGCONT 与 SIGKILL 这种无论进程信号设定如何，都有可能存在副作用的信号添加 Signo 的工具函数：

/// Checks if a signal has kernel-level side effects that must occur
/// even when the signal is ignored.
///
/// SIGCONT and SIGKILL always have side effects (continue/kill process),
/// even when their disposition is SIG_IGN.
pub fn has_side_effect(&self) -> bool {
    matches!(self, Signo::SIGCONT | Signo::SIGKILL)
}

这是为了结合当前 starry-signal 的信号传送逻辑进行更改：

pub fn send_signal(&self, sig: SignalInfo) -> Option<u32> {
    let signo = sig.signo();
-    if self.signal_ignored(signo) {
+   // Only discard signals that have no side effects AND are ignored.
+   // SIGCONT and SIGKILL must always be queued for their side effects.
+   if !signo.has_side_effect() && self.signal_ignored(signo) {
        return None;
    }

    if self.pending.lock().put_signal(sig) {
        self.possibly_has_signal.store(true, Ordering::Release);
    }
    let mut result = None;
    self.children.lock().retain(|(tid, thread)| {
        if let Some(thread) = thread.upgrade() {
            if result.is_none() && !thread.signal_blocked(signo) {
                result = Some(*tid);
            }
            true
        } else {
            false
        }
    });
    result
}

这里通过引入 has_side_effect() 方法，我们将信号分为两类：

1. 普通信号：has_side_effect() == false

   • 如果被 ignore，可以直接丢弃（优化）
   • 不影响内核状态

2. 特殊信号：has_side_effect() == true (仅 SIGCONT 和 SIGKILL)

   • 即使被 ignore，也必须加入队列
   • 因为它们有不可忽略的内核级副作用
   • SIGCONT → 唤醒停止的进程
   • SIGKILL → 强制终止进程

// 只有既没有副作用又被忽略的信号，才真正丢弃
if !signo.has_side_effect() && self.signal_ignored(signo) {
    return None;
}

// 所有其他信号（包括有副作用的 ignored 信号）都加入队列
if self.pending.lock().put_signal(sig) {
    self.possibly_has_signal.store(true, Ordering::Release);
}

这个设计不破坏现有行为，普通信号的处理逻辑完全不变。

这解决了上文的情况 b，即在 SIGCONT 被设置为 Ignore 时未能送达直接被丢弃的问题，保证后续会对其进行处理。

此外，针对线程层面的信号检查函数 check_signals_slow，这个 PR 中也进行了部分接口与功能的更改，将原有的函数接口

fn check_signals_slow(
    &self,
    uctx: &mut UserContext,
    restore_blocked: Option<SignalSet>,
) -> Option<(SignalInfo, SignalOSAction)>

更改为：

fn check_signals_slow(
    &self,
    uctx: &mut UserContext,
    restore_blocked: Option<SignalSet>,
) -> Option<(SignalInfo, Option<SignalOSAction>)> {

主要是更改了返回值类型，从 SignalOSAction 变为 Option<SignalOSAction>。这一返回值类型更改需要结合该函数逻辑部分的扩充来看：

if let Some(os_action) = self.handle_signal(uctx, restore_blocked, &sig, &action) {
    break Some((sig, os_action));
}

原本的 check_signal_slow 会根据当前线程的信号设定 mask 与 sigaction 进行筛选，过滤掉被线程阻塞的信号。这将导致原本的 check_signal_slow 会根据当前线程的信号设定 mask 与 sigaction 进行筛选，过滤掉被线程阻塞的信号，但对于 SIGCONT 这种即使被阻塞或忽略也必须产生副作用的信号，需要特殊处理。

因此，在这里检查过滤信号时增加额外的判断逻辑：

if let Some(os_action) = self.handle_signal(uctx, restore_blocked, &sig, &action) {
    break Some((sig, Some(os_action)));
}

// Special case:
// `SIGCONT` with ignored disposition.
// Even though `handle_signal` returned None (signal ignored),
// we still need to report it for side effects,
// i.e., continue a stopped process even if it ignores `SIGCONT`.
if sig.signo() == Signo::SIGCONT
    && matches!(action.disposition, SignalDisposition::Ignore)
{
    break Some((sig, None));
}

这里主要解决的是情况 b：线程在设置信号处理的 sigaction 的时候设置为忽略（ignore） SIGCONT。如果被处理的信号的是 SIGCONT 并且该信号被设置为 SignalDisposition::Ignore，那么返回的结果是 Some((sig, None))。这允许我们在更加上层的信号处理逻辑中结合进程的具体状态进行判断处理。

StarryOS

最后是关于 StarryOS 本身修改的 PR： #65

为了实现进程的暂停与继续，首先实现状态转换的函数 do_stop 与 do_continue，它们都是调用 starry-process 中的函数判断、更新进程状态，调用 starry-signal 函数移除根据 POSIX 标准需要移除的信号，如 do_stop 的实现逻辑为：

1. 从进程队列中移除所有待处理的 SIGCONT 信号。
2. 从每个线程队列中移除所有待处理的 SIGCONT 信号。
3. 在 ProcessData 中记录停止信号（为了之后的 waitpid 服务）。
4. 将当前进程的状态更改为 STOPPED。
5. 通知父进程此停止状态的变化。

类似的， do_continue负责的主要是：

1. 从进程队列中移除所有待处理的停止信号。
2. 从每个线程队列中移除所有待处理的停止信号。
3. 将当前进程的状态更改为 RUNNING。
4. 恢复进程中的所有线程。
5. 通知父进程此状态变化。

在此基础之上可以实现进程的停止与继续机制。在 new_user_task 之中的 let reason = uctx.run(); 运行退出用户空间之后进行信号检查会调用 api/src/signal.rs 中的 check_signals 函数。

信号检查与处理流程

check_signals 函数是整个信号处理流程的核心入口，它负责检查待处理的信号并执行相应的 OS 级操作。该函数的处理流程如下：

1. SIGCONT 预检查机制

在进行常规信号处理之前，首先对 SIGCONT 进行特殊检查：

// Per POSIX.1-2024, when SIGCONT is sent to a stopped process:
// 1. The process MUST continue (transition from STOPPED to RUNNING), even if:
//    - SIGCONT is blocked by all threads
//    - SIGCONT disposition is SIG_IGN (ignored)
//    - SIGCONT has a custom handler registered
// 2. The signal remains pending if blocked (delivered when unblocked later)
// 3. The handler executes after continuation (if not ignored)

if thr.proc_data.proc.is_stopped() {
    if thr.signal.has_signal(Signo::SIGCONT) || thr.proc_data.signal.has_signal(Signo::SIGCONT) {
        info!(
            "Process {} continuing due to pending SIGCONT (may be blocked)",
            thr.proc_data.proc.pid()
        );
        do_continue();
    }
}

这里使用 has_signal() 而不是 dequeue_signal() 的原因是：即使 SIGCONT 被阻塞，也必须触发进程继续的副作用。信号本身会保留在队列中，等解除阻塞后再递送给处理器。

这个预检查确保了 POSIX 标准的要求：无论 SIGCONT 是否被阻塞或忽略，只要进程处于停止状态，就必须立即继续。

2. 常规信号处理

调用底层的 ThreadSignalManager::check_signals() 获取一个未被阻塞的待处理信号：

let Some((sig, os_action)) = thr.signal.check_signals(uctx, restore_blocked) else {
    return false;
};

如果没有信号待处理，直接返回 false。

3. SIGCONT 的 Ignore 处理

针对 SIGCONT 被设置为 SIG_IGN 的特殊情况：

// Special case:
// SIGCONT with ignored disposition.
// `os_action` is None, but we still need to continue.
// Since the `do_continue` is called initially, we may safely return.
if signo == Signo::SIGCONT && os_action.is_none() {
    return true;
}

因为在步骤 1 中已经调用了 do_continue()，这里直接返回 true 表示信号已处理，无需进一步操作。

4. OS 级操作处理

根据信号的 SignalOSAction 执行相应的内核操作：

match os_action {
    SignalOSAction::Terminate => {
        do_exit(signo as i32, true);
    }
    SignalOSAction::CoreDump => {
        do_exit(128 + signo as i32, true);  // TODO: implement core dump
    }
    SignalOSAction::Stop => {
        do_stop(signo);SIGCONT 被 ignore 时的传递问题
    }
    SignalOSAction::Continue => {
        // Already handled by pre-check
    }
    SignalOSAction::Handler => {
        // User context has been set up, will transfer to handler
    }
}

进程停止机制的实现

进程停止不仅仅是状态的改变，还需要实际阻塞进程中的所有线程。这是通过 handle_stopped_state 函数实现的。

异步阻塞机制

handle_stopped_state 函数在每次系统调用返回用户态前被调用（位于 api/src/task.rs:245-330）：

fn handle_stopped_state(curr: &CurrentTask, thr: &Thread) {
    if !thr.proc_data.proc.is_stopped() {
        return;  // 快速路径：进程未停止，直接返回
    }

    // 使用 async 机制阻塞当前任务
    block_on(poll_fn(|cx| {
        // 第一层检查：状态是否已改变
        if !thr.proc_data.proc.is_stopped() {
            return Poll::Ready(());
        }

        // 第二层检查：是否有 SIGCONT 或 SIGKILL
        if thr.signal.has_signal(Signo::SIGCONT)
            || thr.signal.has_signal(Signo::SIGKILL)
            || thr.proc_data.signal.has_signal(Signo::SIGCONT)
            || thr.proc_data.signal.has_signal(Signo::SIGKILL)
        {
            return Poll::Ready(());
        }

        // 注册 waker 到 stop_event，返回 Pending
        thr.proc_data.stop_event.register(cx.waker());
        Poll::Pending
    }));
}

这里使用了 Rust 的 async 机制：

1. 双层检查保障：

   • 首先检查进程状态是否不再是 STOPPED。在多线程环境下，如果某个线程已经处理了 SIGCONT 并恢复了进程运行，其他线程需要能够检测到这一状态变化并立即退出阻塞。
   • 如果状态仍是 STOPPED，则检查是否有 SIGCONT 或 SIGKILL pending

2. 唤醒机制：

   • Future 注册到 stop_event
   • 当 SIGCONT 或 SIGKILL 被发送时，core/src/task.rs:512 会调用 stop_event.wake() 唤醒所有等待的任务
   • 被唤醒后重新检查条件，决定是继续阻塞还是返回 Ready

唤醒触发点

在 core/src/task.rs 的 send_signal_to_process 函数中：

// Wake the process up, if it is stopped, i.e. blocked on the `stop_event`,
// when a SIGCONT or a SIGKILL arrives
if signo == Signo::SIGCONT || signo == Signo::SIGKILL {
    proc_data.stop_event.wake();
}

这确保了在当前信号的目标进程可能已经由于 SIGSTOP 信号被阻塞，无法按照正常步骤进行信号的检查的情况下，stop_event 也会被触发，唤醒所有阻塞的线程来进行检查。

SIGCONT 三种情况的完整处理

综合以上机制，SIGCONT 在不同情况下的处理如下：

情况 1：SIGCONT 未被 blocked，未被 ignored

这是最正常的情况，只需要直接进行处理，恢复进程执行，并调用用户处理函数（如果配置）：

1. send_signal() 将信号加入队列，返回 true（需要 interrupt）
2. stop_event.wake() 唤醒阻塞的线程
3. task.interrupt() 中断当前任务
4. check_signals() 被调用
5. 预检查检测到 SIGCONT → 调用 do_continue()
6. dequeue_signal() 取出信号
7. 根据 disposition 执行：
   • Default → 已在步骤 5 处理
   • Handler → 执行用户处理器

情况 2：SIGCONT 被 blocked

根据 POSIX 标准的要求：

If SIGCONT is blocked by all threads within the process, there are no threads in a call to a sigwait( ) function selecting SIGCONT, and SIGCONT is not ignored by the process, the SIGCONT signal shall remain pending on the process until it is either unblocked by a thread or a thread calls a sigwait( ) function selecting SIGCONT, or a stop signal is generated for the process or any of the threads within the process.

我们在确保目标进程继续运行的同时应当将这个 SIGCONT 保存在阻塞的信号队列中直到不再被阻塞：

1. send_signal() 将信号加入队列（通过 has_side_effect() 保证），返回 false（blocked，不 interrupt）
2. stop_event.wake() 无条件唤醒
3. handle_stopped_state 中的 Future 被唤醒
4. poll_fn 检查 has_signal(SIGCONT) 为 true → 返回 Ready
5. check_signals() 被调用进行实际的信号处理
6. 预检查检测到 SIGCONT → 调用 do_continue()
7. dequeue_signal() 不会取出信号（因为 blocked）
8. 信号保持 pending 状态仍在队列中，等解除阻塞后再递送

情况 3：SIGCONT 被设置为 Ignore

即使信号已经被忽略，根据前文提及的修改后的 send_signal 仍会将其加入目标进程的信号队列中，后续的信号处理逻辑会针对其特殊检查并处理：

1. send_signal() 中 signal_ignored() 返回 true
2. 但 has_side_effect() 也返回 true
3. 信号被加入队列
4. stop_event.wake() 被调用
5. handle_stopped_state 被唤醒，has_signal(SIGCONT) 返回 true
6. check_signals() 被调用
7. 预检查检测到 SIGCONT → 调用 do_continue()
8. dequeue_signal() 取出信号
9. os_action.is_none() (因为 ignored) → 直接返回 true

总结

本次重构和修复实现了完整的 POSIX 兼容的进程停止与继续机制：

1. starry-process：提供进程状态管理的基础设施
2. starry-signal：
   • 扩展信号队列功能（has_signal, remove_signal, flush_stop_signals）
   • 解决 SIGCONT 被 ignore 时副作用无法执行的问题（引入 has_side_effect()）
   • 正确处理 SIGCONT 被 block 的情况（返回 Option<SignalOSAction>）
3. StarryOS：
   • 实现 do_stop 和 do_continue 状态转换函数
   • 实现 check_signals 信号检查和分发逻辑
   • 实现 handle_stopped_state 异步阻塞机制
   • 双层保障确保 SIGCONT 的副作用一定发生

整个设计通过以下机制协同工作：

• 双层检查：状态检查 + 信号检查
• 双层保障：stop_event.wake() + has_signal() 检查
• 互斥清理：停止信号和 SIGCONT 互相清除
• 原子操作：CAS 保证状态转换的原子性
• 异步机制：高效的任务阻塞和唤醒

相关 PR：

• starry-process: feat: update state machine for process starry-process#5
• starry-signal: feat(signal): support POSIX-compliant SIGCONT and SIGSTOP handling starry-signal#6
• StarryOS: [WIP] feat/process state management #65

[TomGoh]

为了支持后续的 waitpid 的实现，新的 commits 针对进程的停止与继续的信号状态添加了追踪机制，在进程对应的 ProcessSignalManager 中添加相关字段进行追踪与汇报。

POSIX 规范要求 waitpid() 系统调用能够检测三种子进程状态变化：

1. WEXITED: 子进程终止（已有支持）
2. WUNTRACED: 子进程被停止信号（SIGSTOP 等）停止
3. WCONTINUED: 子进程被 SIGCONT 继续运行

目前 StarryOS 中的 waitpid 实现已经支持了第一种情况的 WEXITED，新的 commits 旨在为后两种情况提供支撑。

具体的设计是在 ProcessSignalManager 中添加两个字段：

pub struct ProcessSignalManager {
    ...
    /// Signal event flag, keep track of un-consumed stop/continue event by
    /// `wait`
    signal_events: AtomicU8,
    /// The signal stops the process most recently
    last_stop_signal: SpinNoIrq<Option<Signo>>,
}

前者 signal_event 是一个由 bitflags! 宏定义的标志位，在进程的停止/继续时间发生后标记是否有有未报告的停止/继续事件。
后者 last_stop_signal 用于存储具体导致最近一次停止的信号。
基于这两个新的成员变量，在 ProcessSignalManager 中添加一系列支持原子操作的函数记录信号效果并支持上层系统调用查看、消费事件。整体的事件记录汇报遵循 Record-Query-Consume 的过程。

需要注意的是，这里信号与事件的记录、清除等过程与进程的状态切换相互独立，均由 do_stop 与 do_continue 自行分别进行事件记录与进程状态转换的调用：

pub(crate) fn do_stop(stop_signal: Signo) {
    ...
    // record the stop signal in the `ProcessSignalManager`
    curr_thread.proc_data.signal.set_stop_signal(stop_signal);

    // change the state of current process to `STOPPED`
    curr_process.transition_to_stopped();
    ...
}

pub(crate) fn do_continue() {
    ...
    // record the continue event in the `ProcessSignalManager`
    curr_thread.proc_data.signal.set_cont_signal();

    // change the state of current process to `RUNNING`
    curr_proc.transition_to_running();
    ...
}

结合进程停止/继续过程中对父进程 child_exit_event 的唤醒，整体结构采用了单发布者-单订阅者的发布/订阅模式。由于 POSIX 标准中对于停止/继续事件的要求是：

1. 每个"停止/继续"状态变化最多被父进程观察一次
2. 一旦通过 wait* / waitid 被返回，该状态即被消费

对于连续的、未被消费的同类事件，POSIX 未作记录要求（新事件会覆盖旧事件），因此无需额外设计消息队列，仅保留最新的事件状态即可。

相关 commit:
starry-signal: TomGoh/starry-signal@3726e23