Process

Basic Concepts
When to Use
Available APIs

Basic Concepts

Processes are resource management units in the OS. They can use or wait to use CPUs and use system resources such as memory. They run independently from one another.

The OpenHarmony kernel allows multiple processes to run simultaneously, switch, and communicate, facilitating your management over service programs. In this regard, you will have more time to devote to the implementation of service functionalities.

Processes in the OpenHarmony kernel use the preemptive scheduling mechanism, round-robin (RR) scheduling.

These processes are assigned 32 priorities (0 to 31). Among them, user processes can be configured with 22 priorities from 10 (highest) to 31 (lowest).

A high-priority process can preempt the resources of a low-priority process. The low-priority process can be scheduled only after the high-priority process is blocked or terminated.

Each user-space process has its own memory space, which is invisible to other processes. In this way, processes are isolated from each other.

The user-space root process init is started by the kernel. Then other user-space processes are created by the init process via the fork call.

A process may have the following states:

Init: The process is being created.
Ready: The process is in the ready list and waits for being scheduled by the CPU.
Running: The process is running.
Pending: The process is blocked and suspended. When all threads in a process are blocked, the process is blocked and suspended.
Zombies: The process stops running and waits for the parent process to reclaim its control block resources.

Figure 1 State transition of a process

Description of the process state transition:

Init→Ready:

When a process is created, the process enters the Init state to start initialization after obtaining the process control block. After the process is initialized, the process is inserted into the scheduling queue and therefore enters the Ready state.
Ready→Running:

When a process switchover is triggered, the process with the highest priority in the ready list is executed and enters the Running state. If this process has no thread in the Ready state, the process is deleted from the ready list and resides only in the Running state. However, if it has threads in the Ready state, the process still stays in the ready list. In this case, the process is in both the Ready and Running states.
Running→Pending:

If all threads in a process are entering the Pending state, the process will enter the Pending state together with its last thread. Then, a process switchover is triggered.
Pending→Ready:

When any thread in a Pending process restores to the Ready state, the process is added to the ready list and changes to the Ready state. If a process switchover occurs at this time, the process state changes from the Ready state to the Running state.
Ready→Pending:

When the last ready thread in a process enters the Pending state, the process is deleted from the ready list, and the process changes from the Ready state to the Pending state.
Running→Ready:

A process may change from the Running state to the Ready state in either of the following scenarios:
1. After a process with a higher priority is created or restored, processes will be scheduled. The process with the highest priority in the ready list will change to the Running state, and the originally running process will change from the Running state to the Ready state.
2. If a process has the SCHED_RR scheduling policy and shares the same priority with another process in the Ready state, this process will change from the Running state to the Ready state after its time slices are used up, and the other process with the same priority will change from the Ready state to the Running state.
Running→Zombies:

After the main thread or all threads of a process are stopped, the process changes from the Running state to the Zombies state and waits for the parent process to reclaim resources.

When to Use

After processes are created, you can operate the resources only in your own process space, except shared resources. In user space, processes can be suspended, restored, and delayed. In addition, you can set and obtain the scheduling priority and scheduling policy of processes. When a process is terminated, it proactively releases its resources. However, the PID resources of the process are reclaimed by the parent process via wait/waitpid or when the parent process exits.

Available APIs

The following table describes the APIs provided by the process management module of the OpenHarmony kernel.

Table 1 APIs provided by the process management module

Category	Function	Description	Remarks
Process	fork	Creates a new process.	N/A
	exit	Exits the process.	N/A
	atexit	Registers the callback that will be called when the process is terminated normally.	N/A
	abort	Terminates the process.	N/A
	getpid	Obtains the process ID.	N/A
	getppid	Obtains the parent process ID.	N/A
	getpgrp	Obtains the ID of the process group of the calling process.	N/A
	getpgid	Obtains the process group ID of the process identified by pid.	N/A
	setpgrp	Sets the process group ID of the calling process.	N/A
	setpgid	Sets the process group ID of the process identified by pid.	N/A
	kill	Sends a signal to a specified process.	Only signals 1 to 30 can be sent. The default behavior for signals does not include STOP and CONTINUE and terminates the process without a core dump. SIGSTOP, SIGKILL, and SIGCONT cannot be masked. After an asynchronous signal is sent to a process, the signal callback is invoked only after the process is scheduled. For the sake of security, the process can be killed only by itself, and the kernel cannot forcibly kill the process by sending signals. After the process is killed, SIGCHLD is sent to its parent process. The sending action cannot be canceled. A sleeping process cannot be woken up by a signal.
	wait	Waits for any child process to terminate and reclaims its resources.	The status value is defined by the following macros: WIFEXITED(status): If the child process terminates normally, true is returned. Otherwise, false is returned. WEXITSTATUS(status): If WIFEXITED(status) is true, this macro can be used to obtain the exit code that the child process passed to exit(). WTERMSIG(status): If a child process terminates abnormally, the child process exit code obtained by the parent process through WTERMSIG is always SIGUSR2. This is the only case supported. The following operations are not supported: WIFSTOPPED, WSTOPSIG, WCOREDUMP, and WIFCONTINUED.
	waitpid	Waits for a specified child process to terminate and reclaims its resources.	The options to control the function behavior do not support WUNTRACED and WCONTINUED. The status value is defined by the following macros: WIFEXITED(status): If the child process terminates normally, true is returned. Otherwise, false is returned. WEXITSTATUS(status): If WIFEXITED(status) is true, this macro can be used to obtain the exit code that the child process passed to exit(). WTERMSIG(status): If a child process terminates abnormally, the child process exit code obtained by the parent process through WTERMSIG is always SIGUSR2. This is the only case supported. The following operations are not supported: WIFSTOPPED, WSTOPSIG, WCOREDUMP, and WIFCONTINUED.
Scheduling	getpriority	Obtains the static priority of a specified ID.	PRIO_PGRP and PRIO_USER are not supported. The priority to obtain and set refers to the static priority. The dynamic priority is not involved.
	setpriority	Sets the static priority of a specified ID.
	sched_rr_get_interval	Obtains the execution time limit of a process.	N/A
	sched_yield	Yields the running process.	N/A
	sched_get_priority_max	Obtains the maximum static priority that can be used for a process.	The scheduling policy can only be SCHED_RR.
	sched_get_priority_min	Obtains the minimum static priority that can be used for a process.
	sched_getscheduler	Obtains the scheduling policy of a process.
	sched_setscheduler	Sets a scheduling policy for a process.
	sched_getparam	Obtains scheduling parameters of a process.	N/A
	sched_setparam	Sets scheduling parameters related to a scheduling policy for a process.	N/A
exec	execl	Executes a specified user program file in ELF format.	N/A
	execle	Executes a specified user program file in ELF format.	N/A
	execlp	Executes a specified user program file in ELF format.	N/A
	execv	Executes a specified user program file in ELF format.	N/A
	execve	Executes a specified user program file in ELF format.	N/A
	execvp	Executes a specified user program file in ELF format.	N/A