We now examine the same example under the assumption that the handler can be executed while in kernel mode. Figure 2.3 shows the timing diagram.
Figure 2.3: Restricted Access to the Network Interface, Handler in
the Kernel: An arriving message interrupts the currently running
user application. The kernel, in supervisor mode, receives the
message and deposits it into a buffer. Immediately thereafter,
the handler starts running. To send messages, the handler
simply calls the appropriate kernel function. A return from
interrupt resumes execution of the user application.
As before, the currently running user application is interrupted when a
message arrives. The node switches context at a cost of 
and enters kernel mode. It takes 
time to receive the
message into main memory. Now, however, executing the handler is a
simple and cheap function call. The handler performs the same operations
as before. When it sends a message, it simply calls the appropriate function
in the kernel.
This method saves the time of a context switch to the handler, a
trap into the kernel to restore the originally running process, and
the two traps and returns to send the messages:
We will see in Section 2.2 that safely executing a user
defined handler in the kernel costs additional time. It is the goal
of this work to establish how much overhead is imposed by the various
techniques to execute handlers in kernel mode and compare that to
and other benefits of this approach.
The saving of two traps and returns, 
,
is specific to our example. For handlers that require more
traps into the kernel, the time savings would further increase. For
handlers with fewer kernel requests, the time savings could decrease
to as little as
Most handlers require at least one system call to send a reply.