UNIX

System call fork() is used to create processes. It takes no arguments and 
returns a process ID. The purpose of fork() is to create a new process, which 
becomes the child process of the caller. After a new child process is created, 
both processes will execute the next instruction following the fork() system 
call. Therefore, we have to distinguish the parent from the child. This can be 
done by testing the returned value of fork(): 

• If fork() returns a negative value, the creation of a child process was unsuccessful.
• fork() returns a zero to the newly created child process.

The system call wait() is easy. This function blocks the calling process until one of its 
child processes exits or a signal is received. For our purpose, we shall ignore signals. 
wait() takes the address of an integer variable and returns the process ID of the 
completed process. Some flags that indicate the completion status of the child process 
are passed back with the integer pointer. One of the main purposes of wait() is to wait 
for completion of child processes. 

The execution of wait() could have two possible situations.

1. If there are at least one child processes running when the call to wait() is made, the caller
will be blocked until one of its child processes exits. At that moment, the caller resumes its
execution.
2. If there is no child process running when the call to wait() is made, then this wait() has no
effect at all. That is, it is as if no wait() is there.

The function _exit() terminates the calling process "immediately". More generally, an 
exit in a multithreading environment means that a thread of execution has stopped 
running. For resource management, the operating system reclaims resources (memory, 
files, etc.) that were used by the process. The process is said to be a dead process after
it terminates.Most operating systems allow the terminating process to provide a 
specific exit status to the system, which is made available to the parent process.  The 
exit operation typically performs clean­up operations within the process space before 
returning control back to the operating system. 

 a program that needs to access data from a file stored in a file system uses the read
system call. The file is identified by a file descriptor that is normally obtained from
a previous call to open. This system call reads in data in bytes, the number of which is 
specified by the caller, from the file and stores then into a buffer supplied by the 
calling process. The read system call takes three arguments: 1.The file descriptor
of the file. the buffer where the read data is to be stored and the number of
bytes to be read from the file.
The write is one of the most basic routines provided by a Unix-like operating 
system kernel. It writes data from a buffer declared by the user to a given device, 
such as a file. This is the primary way to output data from a program by directly using
a system call. The destination is identified by a numeric code. The data to be 
written, for instance a piece of text, is defined by a pointer and a size, given in 
number of bytes. write thus takes three arguments: The file code (file descriptor or fd). The
pointer to a buffer where the data is stored (buf). The number of bytes to write from the buffer
(nbytes).

For most file systems, a program initializes access to a file in a file system using the open system
call. This allocates resources associated to the file (the file descriptor), and returns a handle that the
process will use to refer to that file. In some cases the open is performed by the first access. The
same file may be opened simultaneously by several processes, and even by the same process,
resulting in several file descriptors for the same file; depending on the file organization and
filesystem.The pathname to the file, The kind of access requested on the file (read, write, append
etc.), The initial file permission is requested using the third argument called mode. This argument is
relevant only when a new file is being created.

A close system call is a system call used to close a file descriptor by the kernel. For most file
systems, a program terminates access to a file in a filesystem using the close system call. This
flushes file buffers, updates file metadata, which may include and end-of-file indicator in the data;
de-allocates resources associated with the file (including the file descriptor) and updates the system
wide table of files in use. Some programming languages maintain a data structure of files opened by
their runtime library and may close when the program terminates. This practice is known as
resource acquisition is initialization (RAII). Some operating systems will invoke the close on
files held by a program if it terminates. Some operating systems will invoke the close syscall as
part of an operating system recovery as a result of a system failure.

In computing, ioctl (an abbreviation of input/output control) is a system call for device-specific
input/output operations and other operations which cannot be expressed by regular system calls. It
takes a parameter specifying a request code; the effect of a call depends completely on the request
code. Request codes are often device-specific. For instance, a CD-ROM device driver which can
instruct a physical device to eject a disc would provide an ioctl request code to do that. Device-
independent request codes are sometimes used to give userspace access to kernel functions which
are only used by core system software or still under development.

read system call (system_call::read)

The currently executing process wants to read data from the device associated with
connection id given in CPU register 1. The data read from the device are placed in Primary
Store starting at the address given in CPU register 2. The interpretation of the contents of
CPU register 3, n, depends on the type of device from which the data are being read. If the
 disk is being read, then n is the disk block number to read; if the terminal is being read, then n
is the maximum number of characters to read from the terminal.

write system call (system_call::write)

The currently executing process wants to write data to the device associated with connection
id given in CPU register 1. The data written to the device are located in Primary Store starting
at the address given in CPU register 2. The interpretation of the contents of CPU register 3, n,
depends on the type of device to which the data are being written. If the disk is being written,
then n is the disk block number to which the data will be written; if the terminal is being
written, then n is the number of characters to write to the terminal.

getpid() : returns the process ID of the calling process. This is often used by routines that generate
unique temporary filenames.
pid_t getpid(void); getpid() returns the process ID of the current process. It never throws any
error therefore is always successful. If the caller's parent is in a different PID namespace (see
pid_namespaces(7)), getppid() returns 0.

From a kernel perspective, the PID (which is shared by all of the

threads in a multithreaded process) is sometimes also known as the
thread group ID (TGID). This contrasts with the kernel thread ID
(TID), which is unique for each thread.