[Tutor] Running a script in the background

eryksun eryksun at gmail.com
Tue Sep 4 11:14:50 CEST 2012


On Mon, Sep 3, 2012 at 10:21 PM, Dwight Hutto <dwightdhutto at gmail.com> wrote:
> What's wrong with:
>
> But each OS(BIOS handler) has a way of providing/accepting instructions to
> the processor, which is constantly procedural. This has to have a terminal
> at some point.

What do you mean by 'terminal' in this context? A terminal is a device
(possibly virtual) for entering data and displaying output from a
computer.

cron isn't scheduling active processes/threads like the kernel does.
Every minute, it checks a job table and possibly starts one or more
programs. This is an efficient way to schedule a large number of
programs to run at various times throughout the day, week, and month.
Otherwise all of these programs would need to have at least a stub
that runs as a daemon, wasting memory and CPU resources needlessly.

Scheduling processes is an entirely different domain. In a preemptive
multitasking system, it's up to the kernel to schedule access to the
CPU. Each process (or thread on some systems) is assigned a quantum of
ticks. The ticks are based on a hardware timer. Periodically (e.g. 10
milliseconds) this timer triggers a hardware interrupt that enables
the kernel to preempt the current thread. The kernel schedules the
next (possibly the same) process to run, based on a priority scheme,
out of the pool of ready processes.

Preempting a running process requires a context switch, i.e. the
process control block (e.g. PID, priority, execution state such as
running/ready/waiting, CPU number/registers/flags, virtual memory,
signal handlers, I/O, credentials, accounting, etc) has to be saved on
the current stack. Then the PCB of the next process is loaded; the CPU
state is restored; and execution resumes seamlessly.

Here's the task_struct used by the Linux scheduler (lines 1235-1593):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/linux/sched.h#l1235

> What is meant by behind a console, and running without a console, just a
> window system, and a file set that deals with instructions/errors based on
> BIOS input/output?

Windows NT typically boots without a console. It doesn't have virtual
terminals, but you can run console programs in a Win32 console managed
by the Client/Server Runtime Subsystem (csrss.exe)

In contrast, Linux boots in console mode. Typically it maps the
"console" (boot parameter) to the current virtual terminal (i.e.
/dev/tty0), but it could also be a dumb terminal or modem. It creates
several virtual terminals depending on the system configuration.
Debian has tty's 1-63 and runs getty on tty 1-6 to allow text-mode
logins and an Xorg display manager (e.g. lightdm) on tty7 for logging
in to a graphical desktop environment (e.g. xfce4).


More information about the Tutor mailing list