5 ms·

You're joking, but this can be used in a semi-practical way to keep programs alive and mostly functioning, see http://people.csail.mit.edu/rinard/paper/pldi14.p

You're joking, but this can be used in a semi-practical way to keep programs alive and mostly functioning, see http://people.csail.mit.edu/rinard/paper/pldi14.pdf http://people.csail.mit.edu/rinard/paper/pldi14.pdf for instance. The idea here is that you catch certain faulting operations and drop/fix them: segfaulting store? ignore! segfaulting read? manufacture a result value of 0, it's usually not too wrong. And by using LD_PRELOAD magic, this can even be retrofitted onto existing applications without changing or recompiling them.

RMPR 6y ago
Signals always seem (at least to me) to be an early implementation of exceptions
- 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
userbinator 6y ago
When I used to work on Win9x, where badly-behaved programs would often corrupt memory and lead to the system eventually crashing, I made use of that trick a few times --- keeping a kernel debugger resident meant that sometimes I could skip over faulting code and keep the OS alive long enough to save/finish my work and reboot. But often, a lot of things would stop working too, which is not so surprising since if you continue to ignore errors you will eventually end up with an empty program. Also reminds me of this: https://news.ycombinator.com/item?id=4157777 https://news.ycombinator.com/item?id=4157777
- staycoolboy 6y ago
  Did you ever use BlackICE? I worked on Windows drivers in the early 90's and all of our systems had BlackICE running which was like a hypervisor debugger with full hardware control: you could CTRL-ALT-TAB into it and halt the OS at any point and save state. The basic debug strategy was to break to BlackICE on fault, handle it with a macro, and save the OS from crashing. Super useful, also great for breaking copy protection on games. ;-)
  - trasz 6y ago
    Wasn't that SoftIce?
    - KeBugCheckEx 6y ago
      Surely SoftICE.
    - staycoolboy 6y ago
      Wow, yes it was. I have no idea where BlackICE came from in my mind... Thanks!
      - pantalaimon 6y ago
        > I have no idea where BlackICE came from in my mind... Sounds like something from Neuromancer
plorkyeran 6y ago
Norton CrashGuard was an implementation of that idea for Windows. Unsurprisingly, doing anything other than saving your work and restarting after it did its thing was a very bad idea.

RMPR 6y ago

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

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

userbinator 6y ago

When I used to work on Win9x, where badly-behaved programs would often corrupt memory and lead to the system eventually crashing, I made use of that trick a few times --- keeping a kernel debugger resident meant that sometimes I could skip over faulting code and keep the OS alive long enough to save/finish my work and reboot. But often, a lot of things would stop working too, which is not so surprising since if you continue to ignore errors you will eventually end up with an empty program. Also reminds me of this: https://news.ycombinator.com/item?id=4157777 https://news.ycombinator.com/item?id=4157777

staycoolboy 6y ago
Did you ever use BlackICE? I worked on Windows drivers in the early 90's and all of our systems had BlackICE running which was like a hypervisor debugger with full hardware control: you could CTRL-ALT-TAB into it and halt the OS at any point and save state. The basic debug strategy was to break to BlackICE on fault, handle it with a macro, and save the OS from crashing. Super useful, also great for breaking copy protection on games. ;-)
- trasz 6y ago
  Wasn't that SoftIce?
  - KeBugCheckEx 6y ago
    Surely SoftICE.
  - staycoolboy 6y ago
    Wow, yes it was. I have no idea where BlackICE came from in my mind... Thanks!
    - pantalaimon 6y ago
      > I have no idea where BlackICE came from in my mind... Sounds like something from Neuromancer

plorkyeran 6y ago

Norton CrashGuard was an implementation of that idea for Windows. Unsurprisingly, doing anything other than saving your work and restarting after it did its thing was a very bad idea.