About the scheduling of xorg applications

Glynn Clements glynn at gclements.plus.com
Thu Dec 10 06:31:17 PST 2009


ZelluX wrote:

> I'm not familiar with x window system and trying to know some details about
> process scheduling.
> 
> Considering such a situation, some applications are running on x window
> systems and one of them, for example, a web browser has the focus. If there
> comes an interrupt, such as a keyboard interrupt, and now kernel takes over
> the control. My question is that what's the running user-mode application
> now, is it the web browser, xserver, or any process is possible?

A process which is busy executing user-space code is in the "running"
state (shown by an "R" in the STAT field in the output from "ps"),
which means that the kernel will allocate CPU time-slices to it on a
regular basis.

When a process performs a blocking I/O call (e.g. read(), select(),
poll() etc for a socket, pipe or character device, and no data can be
read or written), the kernel will change the process' status to
"interruptible sleep" (shown by an "S"). Sleeping processes aren't
allocated any CPU time.

If you run "ps" with the "l" flag, the WCHAN field will give an
indication as to what a sleeping process is waiting for. A running
process will have a "-" in that field, as it isn't waiting for
anything.

Servicing an interrupt from a device may result in processes which
were waiting for the device changing state from sleeping to running,
in which case the process will start receiving CPU time-slices again. 
The first time-slice won't necessarily be allocated as soon as the
kernel has serviced the interrupt, as other processes with higher
priorities may also be in the running state.

If a process is waiting on a pipe, Unix-domain socket, pty, mutex, or
similar, it will be woken (changed from sleeping to running) when some
other process affects its state (e.g. writes to the other end of a
pipe), rather than in response to a hardware event.

-- 
Glynn Clements <glynn at gclements.plus.com>



More information about the xorg mailing list