Process and Exception Management Kernel Services

The process and exception management kernel services provided by the base kernel provide the capability to:

• Create kernel processes
• Register exception handlers
• Provide process serialization
• Generate and handle signals
• Support event waiting and notification

Creating Kernel Processes

Kernel extensions use the creatp and initp kernel services to create and intialize a kernel process. The setpinit kernel service allow a kernel process to change its parent process from the one that created it to the init process, so that the creating process does not receive the death-of-child process signal upon kernel process termination. "Using Kernel Processes supplies additional information concerning use of these services.

Creating Kernel Threads

Kernel extensions use the thread_create and kthread_start services to create and initialize kernel-only threads. "Understanding Kernel Threads provides more information about threads.

The thread_setsched service is used to control the scheduling parameters, priority and scheduling policy, of a thread.

Kernel Structures Encapsulation

The getpid kernel service is used by a kernel extension in either the process or interrupt environment to determine the current execution environment and obtain the process ID of the current process if in the process environment. The rusage_incr service provides an access to the rusage structure.

The thread-specific uthread structure is also encapsulated. The getuerror and setuerror kernel services should be used to access the ut_error field. The thread_self kernel service should be used to get the current thread's ID.

Registering Exception Handlers

The setjmpx, clrjmpx, and longjmpx kernel services allow a kernel extension to register an exception handler by:

• Saving the exception handler's context with the setjmpx kernel service
• Removing its saved context with the clrjmpx kernel service if no exception occurred
• Starting the next registered exception handler with the longjmpx kernel service if it was unable to handle the exception

Refer to "Handling Exceptions While in a System Call" for additional information concerning use of these services.

Signal Management

Signals can be posted either to a kernel process or to a kernel thread. The pidsig service posts a signal to a specified kernel process; the kthread_kill service posts a signal to a specified kernel thread. A thread uses the sig_chk service to poll for signals delivered to the kernel process or thread in the kernel mode.

"Kernel Process Signal and Exception Handling provides more information about signal management.

Events Management

The event notification services provide support for two types of interprocess communications:

The et_wait and et_post kernel services support single waiter event notification by using mutually agreed upon event control bits for the kernel thread being posted. There are a limited number of control bits available for use by kernel extensions. If the kernel_lock is owned by the caller of the et_wait service, it is released and acquired again upon wakeup.

The following kernel services support a shared event notification mechanism that allows for multiple threads to be waiting on the shared event.

These services support an unlimited number of shared events (by using caller-supplied event words). The following list indicates methods to wait for an event to occur:

• Calling e_assert_wait and e_block_thread successively; the first call puts the thread on the event queue, the second blocks the thread. Between the two calls, the thread can do any job, like releasing several locks. If only one lock, or no lock at all, needs to be released, one of the two other methods should be prefered.
• Calling e_sleep_thread; this service releases a simple or a complex lock, and blocks the thread. The lock can be automatically reacquired at wakeup.

The e_clear_wait service can be used by a thread or an interrupt handler to wake up a specified thread, or by a thread that called e_assert_wait to remove itself from the event queue without blocking when calling e_block_thread. The other wakeup services are event-based. The e_wakeup and e_wakeup_w_result services wake up every thread sleeping on an event queue; while the e_wakeup_one service wakes up only the most favored thread. The e_wakeup_w_sig service posts a signal to every thread sleeping on an event queue, waking up all the threads whose sleep is interruptible.

The e_sleep and e_sleepl kernel services are provided for code that was written for previous releases of the operating system. Threads which have called one of these services are woken up by the e_wakeup, e_wakeup_one, e_wakeup_w_result, e_wakeup_w_sig, or e_clear_wait kernel services. If the caller of the e_sleep service owns the kernel lock, it is released before waiting and is acquired again upon wakeup. The e_sleepl service provides the same function as the e_sleep service except that a caller-specified lock is released and acquired again instead of the kernel_lock.

List of Process , Thread, and Exception Management Kernel Services

The Process, Thread, and Exception Management kernel services are listed below.

Related Information

Understanding Execution Environments.

Understanding Exception Handling.