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).
Usually programs fork() before they do anything that requires threads. To have the program in the "foreground", just fork and wait for a kind of signal from the forked process and exit only when that arrives.
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).