wait (system call)

In computer operating systems, a process (or task) may wait on another process to complete its execution. In most systems, a parent process can create an independently executing child process. The parent process may then issue a wait system call, which suspends the execution of the parent process while the child executes. When the child process terminates, it returns an exit status to the operating system, which is then returned to the waiting parent process. The parent process then resumes execution.

Modern operating systems also provide system calls that allow a process's thread to create other threads and wait for them to terminate ("join" them) in a similar fashion.

An operating system may provide variations of the wait call that allow a process to wait for any of its child processes to exit, or to wait for a single specific child process (identified by its process ID) to exit.

Some operating systems issue a signal (SIGCHLD) to the parent process when a child process terminates, notifying the parent process and allowing it to retrieve the child process's exit status.

The exit status returned by a child process typically indicates whether the process terminated normally or abnormally. For normal termination, this status also includes the exit code (usually an integer value) that the process returned to the system. During the first 20 years of UNIX, only the low 8 bits of the exit code have been available to the waiting parent. In 1989 with SVR4, a new call waitid has been introduced that returns all bits from the exit call in a structure called siginfo_t in the structure member si_status. Waitid is a mandatory part of the POSIX standard since 2001.

Zombies and orphans

When a child process terminates, it becomes a zombie process, and continues to exist as an entry in the system process table even though it is no longer an actively executing program. Under normal operation it will typically be immediately waited on by its parent, and then reaped by the system, reclaiming the resource (the process table entry). If a child is not waited on by its parent, it continues to consume this resource indefinitely, and thus is a resource leak. Such situations are typically handled with a special "reaper" process that locates zombies and retrieves their exit status, allowing the operating system to then deallocate their resources.

Conversely, a child process whose parent process terminates before it does becomes an orphan process. Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits. This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.

If a child process receives a signal, a waiting parent will then continue execution leaving an orphan process behind. Hence it is sometimes needed to check the argument set by wait, waitpid or waitid and, in the case that WIFSIGNALED is true, wait for the child process again to deallocate resources.

gollark: I could probably have it share code with a disassembler, too, although even the ISA-as-currently-implemented allows a bunch of obfuscatory tricks.
gollark: I'm considering implementing the assembler in JS or Python or Rust or something, but it *would* be nice to have this available from within potatOS.
gollark: Honestly that's entirely unnecessary and I would probably only need simple splitting into lines and label handling, but you know.
gollark: That's how you would do it in my thing, using a somewhat insane S-expression assembly-ish language.
gollark: Using hypothetical assembly syntax I haven't actually implemented:```# start of memory to add kittens to(add r1 r0 0x1000) # maybe there would be nice dedicated syntax for "set register" actually# end of kittenized region(add r2 r0 0x1600)(label loop (add r3 r0 40) (poke r3 r1 0) (add r3 r0 94) (poke r3 r1 1) # and so on (add r1 r1 8) (jlt r1 r2 loop))```

See also

References

    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.