> That is kinda insane thing to say. That is like trying to claim that you can't do threads in C++ because you can fork.

If you have more than one thread the only thing you are allowed to call after fork() are async safe functions and only the calling thread will make it into the forked process. Go uses a multi threaded runtime so the state of the runtime will be in an absolute mess in the child process. There generally is no sensible way in which an application can fork after a second thread has been created and how bad this gets, depends very much on the situation. But yes, the same problem applies in any programming language after multiple threads were created.

As I understand it, the problem is that the Go scheduler uses threading to schedule the goroutines, and fork(2) says: "the child process is created with a single thread—the one that called fork()", so your fork then lose access to the scheduler.

Or something along those lines; it's been a while and this kind of stuff isn't really my expertise. I'm sure it's not literally impossible, but I wasn't able to get it to work in a reasonable amount of time so I just shrugged and exec'd xclip instead. The C++ runtime is tiny in comparison, and doesn't do anything like the Go scheduler. I think in general it's just not really considered much of a priority. Modern service managers don't really rely on processes to "daemonize" any more, which was always a bit hacky, and in my 8 years of Go this is the only time I ever wanted to do anything like this.

Go also had trouble with setuid() for the same reason (it would only get set for the current thread on Linux), although IIRC that's long since been fixed (this was around Go 1.5 or so).