4 ms·

Either Linux's fault or Glibc's fault. POSIX mandates getaddrinfo to be thread safe.

• raggi 3y ago
  glibc, I’m too lazy to lookup if it removes the getenv lookup with posix build flags.
• o11c 3y ago
  Yes, but `setenv` is documented as not thread-safe. Once you do unsafe things, the nasal demons can spread to safe code elsewhere. Glibc's documentation is more explicit about the propogation of the nasal demons: ┌─────────────────────┬───────────────┬─────────────────────┐ │Interface │ Attribute │ Value │ ├─────────────────────┼───────────────┼─────────────────────┤ │setenv(), unsetenv() │ Thread safety │ MT-Unsafe const:env │ └─────────────────────┴───────────────┴─────────────────────┘ ┌────────────────┬───────────────┬────────────────────┐ │Interface │ Attribute │ Value │ ├────────────────┼───────────────┼────────────────────┤ │getaddrinfo() │ Thread safety │ MT-Safe env locale │ ├────────────────┼───────────────┼────────────────────┤ │freeaddrinfo(), │ Thread safety │ MT-Safe │ │gai_strerror() │ │ │ └────────────────┴───────────────┴────────────────────┘
  • jxy 3y ago
    It's great that Glibc documents its POSIX violating behavior very well, but it doesn't change the fact that it violates POSIX.
    • o11c 3y ago
      POSIX does document it, it just requires carefully picking through pages and carefully thinking about the wording, unlike the simplicity of GLIBC documentation. For example, the best information is on the page for `exec`.
  • uxp8u61q 3y ago
    This table is unreadable on a narrow screen.
  • anttihaapala 3y ago
    This! And the attributes page explains these even better: const Functions marked with const as an MT-Safety issue non- atomically modify internal objects that are better regarded as constant, because a substantial portion of the GNU C Library accesses them without synchronization. Unlike race, which causes both readers and writers of internal objects to be regarded as MT-Unsafe, this mark is applied to writers only. Writers remain MT-Unsafe to call, but the then-mandatory constness of objects they modify enables readers to be regarded as MT-Safe (as long as no other reasons for them to be unsafe remain), since the lack of synchronization is not a problem when the objects are effectively constant. The identifier that follows the const mark will appear by itself as a safety note in readers. Programs that wish to work around this safety issue, so as to call writers, may use a non-recursive read-write lock associated with the identifier, and guard all calls to functions marked with const followed by the identifier with a write lock, and all calls to functions marked with the identifier by itself with a read lock. and env Functions marked with env as an MT-Safety issue access the environment with getenv(3) or similar, without any guards to ensure safety in the presence of concurrent modifications. We do not mark these functions as MT-Unsafe, however, because functions that modify the environment are all marked with const:env and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the environment can be considered effectively constant in these contexts, which makes the former safe.
• mmis1000 3y ago
  The general rule of unsafe api(usage) is "once you done it, nothing is expected to safe even if it was stated to be". Error can spread in your program in funny way, which also break the program in funny way (think about stack overflow or double free). Unless the manual/document explicitly stated what error can it cause, there is no way to know without actually trigger it.