Hot answers tagged

24

A hardware interrupt is not really part of CPU multitasking, but may drive it. Hardware interrupts are issued by hardware devices like disk, network cards, keyboards, clocks, etc. Each device or set of devices will have its own IRQ (Interrupt ReQuest) line. Based on the IRQ the CPU will dispatch the request to the appropriate hardware driver. (Hardware ...


24

Here's a high-level view of the low-level processing. I'm describing a simple typical architecture, real architectures can be more complex or differ in ways that don't matter at this level of detail. When an interrupt occurs, the processor looks if interrupts are masked. If they are, nothing happens until they are unmasked. When interrupts become unmasked, ...


12

Gilles already described the general case of an interrupt, the following applies specifically to Linux 2.6 on an Intel architecture (part of this is also based on Intel's specifications). An interrupt is an event that changes the sequence of instructions executed by the processor. There are two different kinds of interrupts: Synchronous interrupt (...


11

This is covered in chapter 10 of Linux Device Drivers, 3rd edition, by Corbet et al. It is available for free online, or you may toss some shekels O'Reilly's way for dead tree or ebook forms. The part relevant to your question begins on page 278 in the first link. For what it's worth, here is my attempt to paraphrase those three pages, plus other bits I've ...


10

In simple terms, you can think of make as having a (possibly large) number of steps, where each step takes a number of files as input and creates one file as output. A step might be "compile file.c to file.o" or "use ld to link main.o and file.o into program". If you interrupt make with CtrlC, then the currently executing step will be terminated which will (...


8

All modern operating systems support multitasking. This means that the system is able to execute multiple processes at the same time; either in pseudo-parallel (when only one CPU is available) or nowadays with multi-core CPUs being common in parallel (one task/core). Let's take the simpler case of only one CPU being available. This means that if you ...


8

Ctrl+C sends SIGINT. The conventional action for SIGINT is to return to a program's toplevel loop, cancelling the current command and entering a mode where the program waits for the next command. Only non-interactive programs are supposed to die from SIGINT. So it's natural that Ctrl+C doesn't kill ed, but causes it to return to its toplevel loop. Ctrl+C ...


7

System calls, messaging passing (as described in the Wikipedia article), and interrupts are all things that cause a context switch or a switch from user to kernel mode. As you likely know: kernel mode: programs have a flat or real view of memory, and programs can read/write freely to all memory and all hardware devices directly without restriction. user ...


7

Ctrl+C causes a SIGINT to be sent to the process running. This signal can be caught by the process. In the make source code you can find a trap for this signal in commands.c: /* If we got a signal that means the user wanted to kill make, remove pending targets. */ if (sig == SIGTERM || sig == SIGINT ... remove childrens ... /* Delete any ...


7

The Unix V7 ed(1) source code is a primitive 1,762-line C program with just a few comments, one of which is this highly-enlightening header comment: /* * Editor */ Given that the source code itself does not provide any rationale, you're only going to get it from the program's author. ed was originally written by Ken Thompson in PDP-11 assembly, but you'...


5

watch -n0.1 --no-title cat /proc/interrupts


5

Ctrl+C (control character intr): It will send SIGINT signal to a process and usually application gets abort but the application can handle this signal. For example you can handle a signal with signal() function in C Language. Ctrl+Z (control character susp): It will send SIGTSTP signal to a process to put it in background and like SIGINT it can be handle. ...


4

System calls can be interrupted through the use of signals, such as SIGINT (generated by CTRL+C), SIGHUP, etc. You can only interrupt them by interacting with the system calls through a PID, however when using Unix signals and the kill command. rt_patch & system calls @Alan asked the following follow-up question: Is the possibility to interrupt ...


4

Linux provides two mechanism for monitoring file system events; dnotify and inotify. The older of the two, dnotify, was introduced in kernel version 2.4.0. It allows applications to register to receive notifications on changes in a directory via the fcntl() interface. The notifications themselves are delivered via signals. The dnotify mechanism is limited ...


4

Interrupts are handled by the operating system, threads (or processes, for that matter) aren't even aware of them. In the scenario you paint: Your thread issues a read() system call; the kernel gets the request, realizes that the thread won't do anything until data arrives (blocking call), so the thread is blocked. Kernel allocates space for buffers (if ...


4

As of today, you can mostly forget about the SA_INTERRUPT flag. In between 2.6.18 and 2.6.24 it was just a migration helper for the new IRQF_DISABLED flag. 2.6.24 removed all SA_* flags and replaced them with IRQF_* flags. 2.6.35 marked this "new" flag as deprecated. If you have a kernel before 2.6.18, you'll probably won't use it (see Justin's answer). ...


4

Message passing is a higher level concept of one process sending a message to another. It is implemented by a system ( kernel ) call, asking the kernel to pass the message to the other process. System calls ask the kernel to perform various services for the process. They are implemented by a software interrupt / system trap, which causes the cpu to save ...


4

ed, like other interactive programs, use Ctrl+C to interrupt tasks of the program itself. This is very similar to the normal case, where it interrupts a task running in the shell - a command. From the user perspective, both variants are very similar. The handling of the signal is different: in the usual case, the signal SIGINT is sent to the foreground ...


3

First of all participants involved in interrupt handling are peripheral hardware devices, interrupt controller, CPU, operating system kernel and drivers. Peripheral hardware devices are responsible for interrupt generation. They assert interrupt request lines when they want attention from operating system kernel. These signals are multiplexed by interrupt ...


3

The Linux kernel is reentrant (like all UNIX ones), which simply means that multiple processes can be executed by the CPU. He doesn't have to wait till a disk access read is handled by the deadly slow HDD controller, the CPU can process some other stuff until the disk access is finished (which itself will trigger an interrupt if so). Generally, an interrupt ...


3

I can try to trap the Interrupt at a lower level and inform the gtkmm application. No, that is a kernel space activity. Fortunately, the kernel does report the outcome of certain events via interfaces accessible from userland. It's a little ambiguous in your question whether you want to detect when a block device is attached, or when a filesystem is ...


3

Time-sliced threads are threads executed by a single CPU core without truly executing them at the same time (by switching between threads over and over again). This is the opposite of simultaneous multithreading, when multiple CPU cores execute many threads. Interrupts interrupt thread execution no matter of technology, and when interrupt handling code ...


3

A page fault occurs when a memory access fails because the MMU lookup for the virtual address ended in an invalid descriptor or in a descriptor indicating a lack of permissions (e.g. write attempt to a read-only page). When a page fault occurs, the processor performs a few actions; the details are specific to each processor architectures but the gist is the ...


3

Great classic question about managing jobs and signals with good examples! I've developed a stripped down test script to focus on the mechanics of the signal handling. To accomplish this, after starting the children (loop.sh) in the background, call wait, and upon receipt of the INT signal, kill the process group whose PGID equals your PID. For the ...


3

This is highly platform-specific. Unless you bind to a certain platform (even difference between x86-32 and x86-64 is principal), one can't answer this. But, if to limit it to x86, according to your last comment, I could suggest some information. There are two main styles of service request ("syscall") from user land to kernel land: interrupt-styled and ...


3

If all the following hold More than one CPU in the VM The VM is pinned (via the host) to specific dedicated CPUs (not shared with other VMs) with a 1-1 mapping of VM CPUs to host CPUs The VM has dedicated (e.g. via passthrough) access to storage/network hardware then in-VM IRQ rebalancing still makes sense. Without multiple CPUs within the VM, in-VM IRQ ...


2

There is a good write up here: Older versions of the Linux kernel took great pains to distinguish between "fast" and "slow" interrupts. Fast interrupts were those that could be handled very quickly, whereas handling slow interrupts took significantly longer. Slow interrupts could be sufficiently demanding of the processor, and it was worthwhile to ...


2

For example the 82093AA IO-APIC has I/O redirection table registers (IOREDTBL) which have a writeable bit specifying the trigger mode (which can be level or edge sensitive). These registers seem to be reflected by struct IO_APIC_route_entry in the kernel source. Digging a bit through the 2.6.18 kernel source, one comes across a function setup_IO_APIC_irqs(....


2

ctrl+c doesn't ever kill a program, That's just not what it does. There are a set of signals that the POSIX standard define, these are used to control a running program. First the signals described in the original POSIX.1-1990 standard. Signal Value Action Comment ────────────────────────────────────────────────────────────────────── ...


2

Here is some hardcore trick: Control-Z it will suspend your process and it'll return you the job ID of that process Then: kill -9 %1 (replace 1 with your job ID). Note: Percentage is mandatory!, otherwise you'll kill your init process which means you will kill the kernel and the whole system will crash (so don't put the space in between :)



Only top voted, non community-wiki answers of a minimum length are eligible