Tcl_DetachPids(3)

💖 Tcl_DetachPids(3) — bestie edition 💖

okay so this is a page from the Tcl Library Procedures manual, and it's all about Tcl_DetachPids, Tcl_ReapDetachedProcs, and Tcl_WaitPid — aka the girlies who manage your child processes in the background. no cap, this is the babysitting manual. 🍼✨

---

✨ NAME ✨

Tcl_DetachPids, Tcl_ReapDetachedProcs, Tcl_WaitPid — manage child processes in background 🧚

---

🌸 SYNOPSIS 🌸

#include <tcl.h>

Tcl_DetachPids(numPids, pidPtr)

Tcl_ReapDetachedProcs()

Tcl_Pid
Tcl_WaitPid(pid, statusPtr, options)

---

🎀 ARGUMENTS 🎀

• Tcl_Size numPids (in) — the number of process ids chillin' inside the array that pidPtr is pointing at. count 'em, bestie 🔢
• int *pidPtr (in) — the address of the array holding those numPids process ids. it's giving "here's the group chat roster" 💅
• Tcl_Pid pid (in) — the id of the process (pipe) you're waiting on. the one you're stalking, respectfully 👀
• int *statusPtr (out) — the result of waiting on a process (pipe). either 0 or ECHILD. that's the tea ☕
• int options (in) — the options controlling the wait. WNOHANG says "don't wait" when checking the process — like, peek but don't linger 🫣

---

🦋 DESCRIPTION 🦋

Tcl_DetachPids and Tcl_ReapDetachedProcs hand you a whole mechanism for managing subprocesses that are running in background. why do these even exist? because the parent of a process has to eventually invoke the waitpid kernel call (or one of a few other similar kernel calls) to wait for the child to exit. periodt. until the parent waits for the child, the child's state literally cannot be completely reclaimed by the system. and if a parent keeps creating children and never waits on them? the system's process table will eventually overflow — even if all the children have already exited. 💀 yeah. zombie children but make it filesystem-level. not cute.

Tcl_DetachPids may be called to ask Tcl to take responsibility for one or more processes whose process ids are contained in the pidPtr array passed as argument. the caller presumably has started these processes running in background and does not want to have to deal with them again. it's giving "here, you take the aux cord, i'm done" 🎧

Tcl_ReapDetachedProcs invokes the waitpid kernel call on each of the background processes so that its state can be cleaned up if it has exited. if the process has not exited yet, Tcl_ReapDetachedProcs does not wait for it to exit; it will check again the next time it is invoked. Tcl automatically calls Tcl_ReapDetachedProcs each time the exec command is executed, so in most cases it is not necessary for any code outside of Tcl to invoke Tcl_ReapDetachedProcs. however, if you call Tcl_DetachPids in situations where the exec command may never get executed, you may wish to call Tcl_ReapDetachedProcs from time to time so that background processes can be cleaned up. lowkey a vibe check you gotta run manually. 🧹✨

Tcl_WaitPid is a thin wrapper around the facilities provided by the operating system to wait on the end of a spawned process and to check a whether spawned process is still running. it is used by Tcl_ReapDetachedProcs and the channel system to portably access the operating system. thin wrapper = it's wearing the OS like a little coat. iconic. 👑

---

🔥 KEYWORDS 🔥

background, child, detach, process, wait

---

real talk though: those detached processes are your responsibility now. don't leave them hanging, bestie. the process table has feelings and a finite size. 🫶

---

and that's the whole page!! 💖 this was Tcl's Tcl_DetachPids(3) page, from the Tcl manual — mwah, love you, bye 👑✨💅