Process
Since a process itself forms an environment, environment variables are associated with a single process.
- ex. when we say
process.env
we are talking about getting environment variables that exist during a specific process
If a program is a set of instructions to carry out a specific task, then a process is just a program in execution
a Signal is the way that a process can communicate with the OS
- Signal and interrupt are basically same, but with a small distinction:
- interrupts are generated by the processor and handled by the
- signals are generated by the kernel and handled by the process.
Every time a program wants to do something (like process a key press, or open a file, or exit) that program needs to ask its parent to do it for it (the parent is the kernel)
How a process comes to life
A process comes into existence via actions facilitated by the kernel scheduler.
How a process requests service of the kernel
A process can request the kernel's services by either making a system call or passing a message
- The OS will implement one or the other, but not both.
By accessing these services, the process can do things like
- Accessing hardware related services
- ex. if Zoom needs to access the Camera, or VSCode needs to access your file system
- Spawning new processes
- Communicating with integral kernal services, like scheduling
These system calls serve as interfaces between a process and the OS.
System calls are analogous to calling REST endpoints. The OS provides a library of user functions, which a process can call.
From the perspective of the application making the system call, it is identical to an ordinary procedure call.
Debugging
strace
/truss
,ltrace
andgdb
are generally good ideas for looking at why a process is stuck. (truss -u on Solaris is particularly helpful; I find ltrace too often presents arguments to library calls in an unusable format.) Solaris also has useful /proc-based tools, some of which have been ported to Linux. (pstack is often helpful).
Backlinks