process: expose pending signals cross-platform (currently Linux-only via RLIMIT_SIGPENDING)

[Dylan-M]

Problem

gopsutil currently exposes per-process pending-signal counts on Linux only, and only as a side-effect of RlimitUsageWithContext:

https://github.com/shirou/gopsutil/blob/master/process/process_linux.go#L246-L247

case RLIMIT_SIGPENDING:
    rs.Used = p.sigInfo.PendingProcess

RlimitUsageWithContext is implemented only on Linux by design — the other POSIX platforms gopsutil supports (macOS, FreeBSD, OpenBSD, NetBSD, Solaris, AIX) do not expose "current usage vs. rlimit" through a unified interface the way Linux does via procfs, so they correctly return ErrNotImplementedError. Pending signals themselves, however, are exposed on each of these platforms (via /proc/<pid>/status on Solaris/AIX; kinfo_proc.*_siglist on the BSDs and macOS) — they're just unreachable from gopsutil today because the only existing accessor is coupled to the Linux rlimit implementation.

For context, on AIX the data is already parsed by fillFromStatusWithContext (SigPnd/ShdPnd/SigBlk/SigIgn/SigCgt → p.sigInfo) but currently has no accessor. The information is collected and discarded.

Proposal

Add a cross-platform method on *Process:

func (p *Process) SignalsPendingWithContext(ctx context.Context) (*SignalsStat, error)

Returning a struct along the lines of:

type SignalsStat struct {
    PendingProcess uint64  // signals pending to the whole process (equivalent to Linux's ShdPnd)
    PendingThread  uint64  // signals pending to the representative thread (SigPnd)
    Blocked        uint64  // SigBlk
    Ignored        uint64  // SigIgn
    Caught         uint64  // SigCgt
}

Windows (which does not use POSIX signals) would return ErrNotImplementedError, matching the existing pattern for non-portable methods.

Rationale for diverging from psutil

psutil does not expose pending signals, and gopsutil generally tracks the psutil API. That said:

1. Linux users of gopsutil already have access to this data via RlimitUsageWithContext. The current situation isn't "gopsutil doesn't expose this"; it's "gopsutil exposes this, but only on one platform via an indirect API." That makes non-Linux users second-class for a metric they already need.

2. The data is POSIX-portable. Every supported POSIX platform surfaces pending signals in a documented, stable interface (/proc/<pid>/status on Linux/Solaris/AIX; kinfo_proc.*_siglist on the BSDs and macOS).

3. Use cases exist in observability tooling. The OpenTelemetry hostmetricsreceiver has a process.signals_pending metric that is currently Linux-only specifically because its gopsutil source is Linux-only. Expanding gopsutil coverage unblocks broader platform support in that ecosystem.

I'd be happy to implement this across Linux (refactor to share the existing parsing), macOS, FreeBSD, OpenBSD, NetBSD, Solaris, and AIX if you're open to the direction. I'd be happy to discuss alternative API shapes (e.g., returning signals as part of an extended MemoryInfoEx-style struct, or as separate getters) if you'd prefer.

Thank you for considering.