[Beltalowda]

It's disappointing to see Wayland copied X11's annoying clipboard semantics. I've been using X11 for so long I'm used to it now, kind of, but it still regularly bugs me or leads me to accidentally "lose" some things.

Some time ago I tried to copy something to the X11 clipboard with a Go app, and this is basically impossible as Go can't fork into the background like xclip etc. do, so you need to either depend on a bit of C code or keep the app in the foreground until the selection changes (which isn't really an option for a CLI app).

[lupire]

Why can't a Go program fork into the background?

[the_mitsuhiko]

Because go uses threads.

[lotharcable]

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.

Of course Go can fork processes.

[the_mitsuhiko]

> 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.

[Beltalowda]

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).

[Vogtinator]

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.

[westernpopular]

Makes me wonder if there is a way at all that you could implement a Go fork yourself.