3 ms·

> They are much nicer to use than the Windows equivalent. Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Wind

> They are much nicer to use than the Windows equivalent. Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.

ratboy666 11y ago
Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).
- pjc50 11y ago
  Much of the IPC stuff Linux has to do with signals is done with window messages on Windows, which is usually nicer as you get to handle it in a defined state rather than, say, in the middle of a syscall.
  - zurn 11y ago
    Signals are not generally used for IPC on Linux. Also you can handle them orderly along with other fd events using the standard & portable self-pipe pattern or Linux-specific signalfd.
- rewqfdsa 11y ago
  > What is hard about making signals cooperate? Library A wants to handle SIGSEGV for memory mapping X. Library B wants to handle SIGSEGV for memory mapping Y. Which of them calls sigaction? What if both do? What if then unload one of the libraries? Windows handles this interaction sanely. Sigaction does not. > raise() is supported on Windows, but kill() Windows splits the jobs of signals into structured exceptions and APCs. You can definitely send an APC to another thread: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684954%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
  - fulafel 11y ago
    It's actually alarmingly common for Windows C/C++ apps to paper over crashes with SEH try { } catch (segfault) { /* seems to work */ } this way. Even Microsoft's own apps used to do it, maybe they still do. You run into this when running random apps under a debugger.
    - silon7 11y ago
      There's nothing structured about core dumps. Better to do nothing so the developer can see a clean core dump.
  - ratboy666 11y ago
    sigaction() returns the old action. This permits chaining of the actions. Specifically for SIGSEGV, if Library B does not want the signal, it can invoke Library A (without caring what it is). Similarily, A can invoke B. "Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library.
    - useerup 11y ago
      > Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library. Yup. Which is exactly why Windows is more sane: No chaining, "unloading" (i.e. unsubscribing) can be done robustly. In the absence of a mechanism like SEH on Linux, signals are (mis)used. Signals are a crude, unstructured way of handling internal termination.

ratboy666 11y ago

Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).

pjc50 11y ago
Much of the IPC stuff Linux has to do with signals is done with window messages on Windows, which is usually nicer as you get to handle it in a defined state rather than, say, in the middle of a syscall.
- zurn 11y ago
  Signals are not generally used for IPC on Linux. Also you can handle them orderly along with other fd events using the standard & portable self-pipe pattern or Linux-specific signalfd.
rewqfdsa 11y ago
> What is hard about making signals cooperate? Library A wants to handle SIGSEGV for memory mapping X. Library B wants to handle SIGSEGV for memory mapping Y. Which of them calls sigaction? What if both do? What if then unload one of the libraries? Windows handles this interaction sanely. Sigaction does not. > raise() is supported on Windows, but kill() Windows splits the jobs of signals into structured exceptions and APCs. You can definitely send an APC to another thread: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684954%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- fulafel 11y ago
  It's actually alarmingly common for Windows C/C++ apps to paper over crashes with SEH try { } catch (segfault) { /* seems to work */ } this way. Even Microsoft's own apps used to do it, maybe they still do. You run into this when running random apps under a debugger.
  - silon7 11y ago
    There's nothing structured about core dumps. Better to do nothing so the developer can see a clean core dump.
- ratboy666 11y ago
  sigaction() returns the old action. This permits chaining of the actions. Specifically for SIGSEGV, if Library B does not want the signal, it can invoke Library A (without caring what it is). Similarily, A can invoke B. "Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library.
  - useerup 11y ago
    > Unloading" cannot be done, unless you are aware of the load order. This is a general issue -- dlclose() is reference counted, and you wouldn't know if it actually unloaded the library. Yup. Which is exactly why Windows is more sane: No chaining, "unloading" (i.e. unsubscribing) can be done robustly. In the absence of a mechanism like SEH on Linux, signals are (mis)used. Signals are a crude, unstructured way of handling internal termination.