4 ms·

I'm kind of surprised advocating calling any syscall other than signal to add the handler back again. It's been a long time since I looked at example code, but

I'm kind of surprised advocating calling any syscall other than signal to add the handler back again. It's been a long time since I looked at example code, but back in the mid 90s, everything I saw (and so informed my habits) just set a flag, listened to the signal again if it was something like SIGUSR1 and then you'd pick up the flag on the next iteration of your main loop. Maybe that's also because I think of a signal like an interrupt, and something you want to get done as soon as possible to not cause any stalls to the main program. I notice that nowadays signalfd() looks like a much better solution to the signal problem, but I've never tried using it. I think I'll give it a go in my next project.

qhwudbebd 2y ago
In practice when I tried it, I wasn't sold on signalfd's benefits over the 90s style self-pipe, which is reliably portable too. Either way, being able to handle signals in a poll loop is much nicer than trying to do any real work in an async context.
formerly_proven 2y ago
This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawyers.
- lilyball 2y ago
  Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe as of POSIX.1-2008 TC2.
  - tedunangst 2y ago
    That's the point. They weren't added until TC2 in 2016.
    - lilyball 2y ago
      Right, it wasn't promised to be safe until then. That doesn't mean it was definitively unsafe before, just that you couldn't rely on it being safe. My question is how would a function like strcmp() actually end up being unsafe in practice given the trivial nature of what it does.
  - lmm 2y ago
    > surely it doesn't touch any global (or per-thread) state Not necessarily. An implementation might choose to e.g. use some kind of cache similar to what the JVM does with interned strings, and then a function like strcmp() might behave badly if it happened to run while that cache was halfway through being rebuilt.
    - SomeoneFromCA 2y ago
      Contrived example, never seen in reality.
      - jcul 2y ago
        You could be surprised. For example, recently I wanted to call `gettid()` in a signal handler. Which I guessed was just a simple wrapper around the syscall. However, it seems this can cache the thread ID in thread local storage (can't remember exact details). I switched to making a syscall instead.
        SomeoneFromCA 2y ago
        Well, this is possible for sure, but not for primitive functions, such as strcmp. It just does not happen in practice.

qhwudbebd 2y ago

In practice when I tried it, I wasn't sold on signalfd's benefits over the 90s style self-pipe, which is reliably portable too. Either way, being able to handle signals in a poll loop is much nicer than trying to do any real work in an async context.

formerly_proven 2y ago

This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawyers.

lilyball 2y ago
Why can't you call strcmp? I think a general practice of "only call functions that are explicitly blessed as async-signal-safe" is a good idea, which means not calling strcmp as it hasn't been blessed, but surely it doesn't touch any global (or per-thread) state so how can it corrupt program state? Update: according to https://man7.org/linux/man-pages/man7/signal-safety.7.html https://man7.org/linux/man-pages/man7/signal-safety.7.html strcmp() actually is async-signal-safe as of POSIX.1-2008 TC2.
- tedunangst 2y ago
  That's the point. They weren't added until TC2 in 2016.
  - lilyball 2y ago
    Right, it wasn't promised to be safe until then. That doesn't mean it was definitively unsafe before, just that you couldn't rely on it being safe. My question is how would a function like strcmp() actually end up being unsafe in practice given the trivial nature of what it does.
- lmm 2y ago
  > surely it doesn't touch any global (or per-thread) state Not necessarily. An implementation might choose to e.g. use some kind of cache similar to what the JVM does with interned strings, and then a function like strcmp() might behave badly if it happened to run while that cache was halfway through being rebuilt.
  - SomeoneFromCA 2y ago
    Contrived example, never seen in reality.
    - jcul 2y ago
      You could be surprised. For example, recently I wanted to call `gettid()` in a signal handler. Which I guessed was just a simple wrapper around the syscall. However, it seems this can cache the thread ID in thread local storage (can't remember exact details). I switched to making a syscall instead.
      - SomeoneFromCA 2y ago
        Well, this is possible for sure, but not for primitive functions, such as strcmp. It just does not happen in practice.