4 ms·

this is not a unix beartrap, this is a bug in Go if that's where it was found. If your code is multithreaded, it's up to you to make it threadsafe. You can't de

this is not a unix beartrap, this is a bug in Go if that's where it was found. If your code is multithreaded, it's up to you to make it threadsafe. You can't declare you're creating the most threadsafe memorysafe newbie safe system, and then go home. You have to write the code. Your program gets its own copy of the environment when the program was launched. Nobody is changing it on you, any contention for that resource is you contending with yourself. You don't expect an operating system to change things out from under you. Unix doesn't. If there is contention for this resource, it's all you (or whoever wrote the library you are using) The environment is name-value pairs, as strings. That's it. That's what makes it accessible and useful. You can swallow it up, the whole thing, into whatever data structure you prefer in your language in a few lines of code, and a millisecond (if that much) of runtime. Just learn how things work and you won't feel helpless.

nvy 3y ago
I'm confused, aren't we talking about the getaddrinfo() syscall? It definitely seems like that syscall is a (multithreaded) footgun that Go just happened to hit.
- fsckboy 3y ago
  a "syscall" is not going to call back into your code to get the environment. If a "syscall" is using your environment, it's part of your code, probably better described as a library call.
  - saagarjha 3y ago
    Few people make raw syscalls.
- dundarious 3y ago
  It's not a syscall, it's a C standard library function that may read files, talk to dbus, read env vars, etc. The problem is people quite understandably expect its re-entrancy to mean more than it really means.
  - nvy 3y ago
    Oh, that's my error. Shows you how much code I write that calls into libc, i.e. almost none.
    - Macha 3y ago
      If you write anything other than Go or Zig on Linux, you're probably calling libc without realising.
      - nvy 3y ago
        Obviously. But I meant directly writing the code that calls into libc myself.
dundarious 3y ago
Most people would expect getaddrinfo to be re-entrant, and in the Linux man 3 page it is: https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html There is no clear/obvious mention of the fact that setenv could interfere with it. It is a glibc footgun/beartrap that this re-entrancy doesn't actually mean calling it with non-shared memory in the arguments ensures no data races.
- fsckboy 3y ago
  there could very well be a bug. if there's a bug, fix it. But from what I read, it's documented as not threadsafe and this problem is happening in a threaded environment. That still could be called a bug. You find bugs, you fix them; That's better than hyperventilating about how there is some massive problem with an operating system that you are using because all the people who came before you who knew more than you decided it was the best thing to use. The other OSes sucked more. This OS is simple enough that you can actually learn how it works, it's all laid out in front of you. Should it do some additional things? sure. Help write the code.
  - dundarious 3y ago
    A beartrap/footgun means "a bit too easy to harm yourself for comfort", not "there is a bug". I am relatively old and have been programming to this interface for a few decades, so I'm not hyperventilating about it. My point (which made reference to the actual OS documentation) was that it takes being bit by such issues before you learn what this "Attributes" section means: > │Interface │ Attribute │ Value │ > │getaddrinfo() │ Thread safety │ MT-Safe env locale │ For the 1st decade of my career, I just searched for "re-entrant", "reentrant", or "MT" and went on my merry way, without realizing the importance of the other possible values of attributes table: in this case "env". It's worth highlighting!
    - fsckboy 3y ago
      when you read the doc and realized you missed something, don't say "footgun", say "aha! I misunderstood" Then if you want, set about to make things better. Instead of jumping to "It shouldn't work this way" consider "Hmmm, why does it work this way? Is it possible that Thompson, Kernighan and Ritchie knew more about how to make a coherent straightforward system that would last 50 years in 1970 than I know how to now?"
saagarjha 3y ago
This is the viewpoint of someone who works alone or on small teams, where all the code in the process is their own. In a complex program there is plenty that can do surprising things that you didn’t expect.
- fsckboy 3y ago
  no, this is a person who understands what is there. People who imagine something else is there, are disappointed when it's not. People who try to invent the new new, and don't complete the task, blame unix, when unix just does what unix said it would do. It was the people who made bigger claims but did not deliver who should step up and say "I didn't turn the unix environment into what I thought I did." but people trying to invent the new new are trying to invent it on unix because unix delivers what it promises. It doesn't deliver what you promise. But have some humility, and accept your failure and don't try to pin it on unix. Go implement on Windows. Unix does allow you to deliver what you promise, that's why you'll still be complaining about unix 10 years from now, but it's up to you to deliver what you promise. people who say "footgun" are people who try to shed responsibility; "it wasn't my fault, waaaaaah". I'm not saying we should not make computers easier to program, I'm saying that when we fail to: "it's a poor worker who blames his tools." Why is it so important to you to blame this on unix, when you could blame it on a mistaken implementation of a library that could be fixed?
  - moring 3y ago
    The words "blame" and "guilt" do not even appear in the article, and "fault" only as part of "segfaulting". Rachel merely points out an easy-to-make mistake before others make them, to save them time. She isn't talking about who is to blame. No need to get defensive.

nvy 3y ago

I'm confused, aren't we talking about the getaddrinfo() syscall? It definitely seems like that syscall is a (multithreaded) footgun that Go just happened to hit.

fsckboy 3y ago
a "syscall" is not going to call back into your code to get the environment. If a "syscall" is using your environment, it's part of your code, probably better described as a library call.
- saagarjha 3y ago
  Few people make raw syscalls.
dundarious 3y ago
It's not a syscall, it's a C standard library function that may read files, talk to dbus, read env vars, etc. The problem is people quite understandably expect its re-entrancy to mean more than it really means.
- nvy 3y ago
  Oh, that's my error. Shows you how much code I write that calls into libc, i.e. almost none.
  - Macha 3y ago
    If you write anything other than Go or Zig on Linux, you're probably calling libc without realising.
    - nvy 3y ago
      Obviously. But I meant directly writing the code that calls into libc myself.

dundarious 3y ago

Most people would expect getaddrinfo to be re-entrant, and in the Linux man 3 page it is: https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html There is no clear/obvious mention of the fact that setenv could interfere with it. It is a glibc footgun/beartrap that this re-entrancy doesn't actually mean calling it with non-shared memory in the arguments ensures no data races.

fsckboy 3y ago
there could very well be a bug. if there's a bug, fix it. But from what I read, it's documented as not threadsafe and this problem is happening in a threaded environment. That still could be called a bug. You find bugs, you fix them; That's better than hyperventilating about how there is some massive problem with an operating system that you are using because all the people who came before you who knew more than you decided it was the best thing to use. The other OSes sucked more. This OS is simple enough that you can actually learn how it works, it's all laid out in front of you. Should it do some additional things? sure. Help write the code.
- dundarious 3y ago
  A beartrap/footgun means "a bit too easy to harm yourself for comfort", not "there is a bug". I am relatively old and have been programming to this interface for a few decades, so I'm not hyperventilating about it. My point (which made reference to the actual OS documentation) was that it takes being bit by such issues before you learn what this "Attributes" section means: > │Interface │ Attribute │ Value │ > │getaddrinfo() │ Thread safety │ MT-Safe env locale │ For the 1st decade of my career, I just searched for "re-entrant", "reentrant", or "MT" and went on my merry way, without realizing the importance of the other possible values of attributes table: in this case "env". It's worth highlighting!
  - fsckboy 3y ago
    when you read the doc and realized you missed something, don't say "footgun", say "aha! I misunderstood" Then if you want, set about to make things better. Instead of jumping to "It shouldn't work this way" consider "Hmmm, why does it work this way? Is it possible that Thompson, Kernighan and Ritchie knew more about how to make a coherent straightforward system that would last 50 years in 1970 than I know how to now?"

saagarjha 3y ago

This is the viewpoint of someone who works alone or on small teams, where all the code in the process is their own. In a complex program there is plenty that can do surprising things that you didn’t expect.

fsckboy 3y ago
no, this is a person who understands what is there. People who imagine something else is there, are disappointed when it's not. People who try to invent the new new, and don't complete the task, blame unix, when unix just does what unix said it would do. It was the people who made bigger claims but did not deliver who should step up and say "I didn't turn the unix environment into what I thought I did." but people trying to invent the new new are trying to invent it on unix because unix delivers what it promises. It doesn't deliver what you promise. But have some humility, and accept your failure and don't try to pin it on unix. Go implement on Windows. Unix does allow you to deliver what you promise, that's why you'll still be complaining about unix 10 years from now, but it's up to you to deliver what you promise. people who say "footgun" are people who try to shed responsibility; "it wasn't my fault, waaaaaah". I'm not saying we should not make computers easier to program, I'm saying that when we fail to: "it's a poor worker who blames his tools." Why is it so important to you to blame this on unix, when you could blame it on a mistaken implementation of a library that could be fixed?
- moring 3y ago
  The words "blame" and "guilt" do not even appear in the article, and "fault" only as part of "segfaulting". Rachel merely points out an easy-to-make mistake before others make them, to save them time. She isn't talking about who is to blame. No need to get defensive.