Function names_an_owner 

pub fn names_an_owner(kind: c_int, pid: c_int) -> bool

Whether F_GETOWN_EX’s answer, owner type kind and pid pid, names an owner the guest could receive a signal from.

A nonzero pid is an owner. f_getown_ex reports pid 0 both for no owner and for an owner the reader’s PID namespace cannot see (pid_vnr, fs/fcntl.c:261-301). An unseen process or thread is never a guest process, since every guest process is a descendant of the reader in its namespace. That holds only while the reader sees every guest process: Hermit’s launch reads from the container’s PID namespace, where every guest process lives, and Detcore reads from the caller’s, which on the in-guest backends (the only ones that read this) is that same namespace, since they admit no nested PID namespace (they refuse every clone but a plain fork, and Detcore refuses unshare and setns on every backend, syscall_classification::is_mount_ns_admin_refused_syscall). A backend that admitted one would have to read from the container’s namespace instead. f_getown_ex also reports pid 0 when the owner’s pid has no task of the owner’s type (pid_task), and one case of that is a live owner: an F_SETOWN or F_OWNER_PID owner naming a thread that is not its process’s leader, which send_sigio still signals. That needs a guest process with a second thread, and the in-guest backends refuse thread creation (clone_args_are_plain_fork), so no guest process has one: a second precondition beside the PID namespace’s, and one a backend that admitted threads would have to meet another way. An unseen process group can still hold the guest, which keeps the group it starts in, so an owner of type F_OWNER_PGRP counts as an owner whatever its pid: that can only refuse more (the one ambiguous disarm is F_SETOWN_EX of a process group with pid 0).