3 ms·

Signals always seem (at least to me) to be an early implementation of exceptions

by RMPR 6y ago

monocasa 6y ago
Sort of? They're really an implementation of interrupts, but sitting on the kernel/user boundary rather than the hardware/kernel boundary. It's a hold over from when a process was really thought of as closer to a virtualized computer rather than a distinct concept in it's own right. And it's not uncommon for the interrupts managing CPU faults to be called exceptions https://wiki.osdev.org/Exceptions https://wiki.osdev.org/Exceptions , so their nomenclature does converge if you squint hard enough.
- Animats 6y ago
  "It's not uncommon for the interrupts managing CPU faults to be called exceptions, so their nomenclature does converge..." An interrupt and a CPU exception are different things. UNIX treats them similarly because the PDP-11 did. An interrupt is something outside the CPU wanting to be serviced, like an I/O completion. An interrupt can be deferred during a critical section, which is what "preventing interrupts" does. Some machines direct interrupts to one of many CPUs, so whoever is free can handle I/O. Interrupts have priorities, queuing, and are handled like events on a queue. A hardware exception is the CPU doing something that stops execution. Inaccessible memory - could be the need to page something in from disk, or a program error. The OS has to decide that. Floating point overflow. Divide by zero. An illegal instruction. The CPU can't continue. So exceptions cannot be deferred, even if in a critical section. The CPU that raised the exception must handle the exception; it can't be handled by another CPU. UNIX/Linux signals are rarely used for I/O completions in user space, but that is supported. See "aio".[1] Apparently Oracle uses this. [1] https://man7.org/linux/man-pages/man7/aio.7.html https://man7.org/linux/man-pages/man7/aio.7.html
  - monocasa 6y ago
    CPU exceptions are very much a type of interrupt (and vis-versa). You can see NMIs for examples of interrupts outside the CPU that can't be deferred like the distinction you're making. Additionally software interrupts are an example of interrupts that come from user space and can't be deferred from user space's perspective, but must be handled before their instruction stream continues. You can also see processors like slave DSPs who's exceptions are routed to other processors to be handled just like any other interrupt on that other core. The N64's RSP, and the Cell's SPEs are great examples of this. You gave the example of AIO for peripheral interruption to user space like an interrupts, (which is used by more than just Oracle), but the classic example is SIGLARM as a corollary to a timer interrupt. This is not a Unix/PDP-11 thing, but pretty much every hardware arch and every OS out there. I say this as someone who's ported a non Unix derived RTOS to MIPS, PowerPC, ARMv7A, ARMv7M, ARMv8-A64, X86_64 linux user mode, Microblaze, and SH4, and has written drivers for Linux, FreeBSD, Windows CE, Windows NT, and that aforementioned RTOS.
    - Animats 6y ago
      You can also see processors like slave DSPs who's exceptions are routed to other processors to be handled just like any other interrupt on that other core. The N64's RSP, and the Cell's SPEs are great examples of this. That's more of a support processor thing, where the special-purpose processor doesn't really do interrupts. GPU exceptions usually create interrupts in the controlling CPU, for example, rather than being handled within the GPU. (How the GPUs should talk to the CPUs is a whole subject in its own right.) Timer interrupts are usually deferrable. The Cell. Is it totally gone now? (If they'd had, say, 16MB/SPE instead of 256K, it might have been good for something.)
      - monocasa 6y ago
        > GPU exceptions usually create interrupts in the controlling CPU, for example, rather than being handled within the GPU I would say that's out of date. GPU exceptions typically don't exist for most shader code (unmapped memory loads are just RAZ, division by zero is defined and doesn't trap, etc.). For the ones that do exist, they're typically handled on GPU these days for latency reasons, but that's just a config register to route it externally or not.' > Timer interrupts are usually deferrable. I didn't say they weren't. Just like SIGALRM can be masked. > The Cell. Is it totally gone now? (If they'd had, say, 16MB/SPE instead of 256K, it might have been good for something.) 16MB would have never made sense. You're only supposed to keep the working set in memory, and 64x the amount of memory was never in the cards from a gate count perspective.
tom_mellior 6y ago
With sigaction handlers (as opposed to the C standard library's simplistic signal handlers) it's not just exceptions, it's more general, like a condition system like in Common Lisp. From inside the handler you can analyze what's wrong, then manipulate the program state and then restart the computation where you were, or at the next instruction, or wherever else you choose. In contrast, your typical exception mechanism (as in Python or C++ or Java or whatever) will unwind the stack and make it impossible to restart from the exact place where the problem occurred.
numpad0 6y ago
To me exceptions seem like interrupts for Java, and callback hell JavaScript webapps are like CPU that runs on unregulated interrupts instead of electrical current

Signals always seem (at least to me) to be an early implementation of exceptions

by RMPR 6y ago

Signals always seem (at least to me) to be an early implementation of exceptions

Sort of? They're really an implementation of interrupts, but sitting on the kernel/user boundary rather than the hardware/kernel boundary. It's a hold over from when a process was really thought of as closer to a virtualized computer rather than a distinct concept in it's own right. And it's not uncommon for the interrupts managing CPU faults to be called exceptions https://wiki.osdev.org/Exceptions https://wiki.osdev.org/Exceptions , so their nomenclature does converge if you squint hard enough.

Animats 6y ago
"It's not uncommon for the interrupts managing CPU faults to be called exceptions, so their nomenclature does converge..." An interrupt and a CPU exception are different things. UNIX treats them similarly because the PDP-11 did. An interrupt is something outside the CPU wanting to be serviced, like an I/O completion. An interrupt can be deferred during a critical section, which is what "preventing interrupts" does. Some machines direct interrupts to one of many CPUs, so whoever is free can handle I/O. Interrupts have priorities, queuing, and are handled like events on a queue. A hardware exception is the CPU doing something that stops execution. Inaccessible memory - could be the need to page something in from disk, or a program error. The OS has to decide that. Floating point overflow. Divide by zero. An illegal instruction. The CPU can't continue. So exceptions cannot be deferred, even if in a critical section. The CPU that raised the exception must handle the exception; it can't be handled by another CPU. UNIX/Linux signals are rarely used for I/O completions in user space, but that is supported. See "aio".[1] Apparently Oracle uses this. [1] https://man7.org/linux/man-pages/man7/aio.7.html https://man7.org/linux/man-pages/man7/aio.7.html
- monocasa 6y ago
  CPU exceptions are very much a type of interrupt (and vis-versa). You can see NMIs for examples of interrupts outside the CPU that can't be deferred like the distinction you're making. Additionally software interrupts are an example of interrupts that come from user space and can't be deferred from user space's perspective, but must be handled before their instruction stream continues. You can also see processors like slave DSPs who's exceptions are routed to other processors to be handled just like any other interrupt on that other core. The N64's RSP, and the Cell's SPEs are great examples of this. You gave the example of AIO for peripheral interruption to user space like an interrupts, (which is used by more than just Oracle), but the classic example is SIGLARM as a corollary to a timer interrupt. This is not a Unix/PDP-11 thing, but pretty much every hardware arch and every OS out there. I say this as someone who's ported a non Unix derived RTOS to MIPS, PowerPC, ARMv7A, ARMv7M, ARMv8-A64, X86_64 linux user mode, Microblaze, and SH4, and has written drivers for Linux, FreeBSD, Windows CE, Windows NT, and that aforementioned RTOS.
  - Animats 6y ago
    You can also see processors like slave DSPs who's exceptions are routed to other processors to be handled just like any other interrupt on that other core. The N64's RSP, and the Cell's SPEs are great examples of this. That's more of a support processor thing, where the special-purpose processor doesn't really do interrupts. GPU exceptions usually create interrupts in the controlling CPU, for example, rather than being handled within the GPU. (How the GPUs should talk to the CPUs is a whole subject in its own right.) Timer interrupts are usually deferrable. The Cell. Is it totally gone now? (If they'd had, say, 16MB/SPE instead of 256K, it might have been good for something.)
    - monocasa 6y ago
      > GPU exceptions usually create interrupts in the controlling CPU, for example, rather than being handled within the GPU I would say that's out of date. GPU exceptions typically don't exist for most shader code (unmapped memory loads are just RAZ, division by zero is defined and doesn't trap, etc.). For the ones that do exist, they're typically handled on GPU these days for latency reasons, but that's just a config register to route it externally or not.' > Timer interrupts are usually deferrable. I didn't say they weren't. Just like SIGALRM can be masked. > The Cell. Is it totally gone now? (If they'd had, say, 16MB/SPE instead of 256K, it might have been good for something.) 16MB would have never made sense. You're only supposed to keep the working set in memory, and 64x the amount of memory was never in the cards from a gate count perspective.

tom_mellior 6y ago

With sigaction handlers (as opposed to the C standard library's simplistic signal handlers) it's not just exceptions, it's more general, like a condition system like in Common Lisp. From inside the handler you can analyze what's wrong, then manipulate the program state and then restart the computation where you were, or at the next instruction, or wherever else you choose. In contrast, your typical exception mechanism (as in Python or C++ or Java or whatever) will unwind the stack and make it impossible to restart from the exact place where the problem occurred.

numpad0 6y ago

To me exceptions seem like interrupts for Java, and callback hell JavaScript webapps are like CPU that runs on unregulated interrupts instead of electrical current