4 ms·

Excerpt from C11: "[...] errno which expands to a modifiable lvalue that has type int and thread local storage duration"

pjmlp 4y ago
Still doesn't cover signals, only works if C11 threads are being used (it is all open if OS threads follow the same TLS mechanism), and those C89 and C99 code bases get nothing from it anyway.
- quietbritishjim 4y ago
  In practice it works with major thread implementations even before C11, even though it doesn't say so in the standard. You can't call OS functions from a signal handler so I can't see why signals would matter. Have I missed something?
  - cesarb 4y ago
    > You can't call OS functions from a signal handler You can, as long as these functions are "async signal safe", see https://man7.org/linux/man-pages/man7/signal-safety.7.html https://man7.org/linux/man-pages/man7/signal-safety.7.html for details.
    - quietbritishjim 4y ago
      Oh wow. I mean, fair enough for simple utilities like strlen(). But open(), write(), close()? I had no idea.
  - pjmlp 4y ago
    You can, it is UB in what might happen, you either get lucky, or not. Don't expect a compiler error, this is C, where the programmer knows best.
    - jstimpfle 4y ago
      You can call any system function that is marked as async-signal-safe. Whether that's a great idea is a different question. > Don't expect a compiler error, this is C, where the programmer knows best. As for this snark, these considerations are pretty much OS and concurrency stuff that transcend any implementation language [0]. No one prevents you to switch back to single-threaded cushy OOP-y Javascript, however note that someone has to implement and run that for you. [0] yes, signals aren't beautiful, and in 2023 a beautifully designed OS might better do delivery of asynchronous messages using event handling and/or using dedicated threads. However, that's computing history for you, and it can be worked with. If you don't like it find a different platform. C doesn't really require signals, and if you use Unix with a different language, signals won't just go away.
      - pjmlp 4y ago
        Indeed, "Transcending POSIX: The End of an Era?" https://www.usenix.org/publications/loginonline/transcending-posix-end-era https://www.usenix.org/publications/loginonline/transcending...
        jstimpfle 4y ago
        So you're going back to URL firing mode, instead of making clear statements that are reasonably backed up?

pjmlp 4y ago

Still doesn't cover signals, only works if C11 threads are being used (it is all open if OS threads follow the same TLS mechanism), and those C89 and C99 code bases get nothing from it anyway.

quietbritishjim 4y ago
In practice it works with major thread implementations even before C11, even though it doesn't say so in the standard. You can't call OS functions from a signal handler so I can't see why signals would matter. Have I missed something?
- cesarb 4y ago
  > You can't call OS functions from a signal handler You can, as long as these functions are "async signal safe", see https://man7.org/linux/man-pages/man7/signal-safety.7.html https://man7.org/linux/man-pages/man7/signal-safety.7.html for details.
  - quietbritishjim 4y ago
    Oh wow. I mean, fair enough for simple utilities like strlen(). But open(), write(), close()? I had no idea.
- pjmlp 4y ago
  You can, it is UB in what might happen, you either get lucky, or not. Don't expect a compiler error, this is C, where the programmer knows best.
  - jstimpfle 4y ago
    You can call any system function that is marked as async-signal-safe. Whether that's a great idea is a different question. > Don't expect a compiler error, this is C, where the programmer knows best. As for this snark, these considerations are pretty much OS and concurrency stuff that transcend any implementation language [0]. No one prevents you to switch back to single-threaded cushy OOP-y Javascript, however note that someone has to implement and run that for you. [0] yes, signals aren't beautiful, and in 2023 a beautifully designed OS might better do delivery of asynchronous messages using event handling and/or using dedicated threads. However, that's computing history for you, and it can be worked with. If you don't like it find a different platform. C doesn't really require signals, and if you use Unix with a different language, signals won't just go away.
    - pjmlp 4y ago
      Indeed, "Transcending POSIX: The End of an Era?" https://www.usenix.org/publications/loginonline/transcending-posix-end-era https://www.usenix.org/publications/loginonline/transcending...
      - jstimpfle 4y ago
        So you're going back to URL firing mode, instead of making clear statements that are reasonably backed up?