[the_mitsuhiko]

This design has the really annoying situation that applications closing down can't leave stuff in the clipboard. This results in a quite a frustrating behavior for users and also makes command line tools tricky. wl-clipboard lets you pipe text into the command to copy. The way it works is that it daemonizes in the background to fulfill the copy request. It either cancels on the first paste (command) or until some other application copies something into the clipboard. It's not completely awful design, but I'm surprised that the protocol does not offer at least the option to move content into the clipboard and exit.

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

[GaryPalmer]

I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?

[masklinn]

> I don't get it (Windows user). If I copy some text in the browser and then close the browser the clipboard is gone under linux? How is that good design, wouldn't it be preferable if the OS is holding the clipboard data as a middle man?

The essay covers this: it was picked because it means only the pasted data (of the right mimetype) gets copied, so it avoids unnecessary copies. This is especially useful if the source can generate large amounts of data e.g. an image program is able to copy in multiple image formats, in which case said program would have to export everything to the OS on copy.

But yes that also means all the data is lost unless the source program takes extra non-trivial measures to keep the data alive.

This made some sick kind of sense in X11, because all that data might have to transit over the network too if you were using remote X.

[the_mitsuhiko]

It's horrible design. It's basically an omission of one of the most critical parts of how the Windows/macOS clipboard APIs actually function where data can optionally be frozen. For whatever reason the wayland folks thought they can get away without that functionality and from what I can tell (as user and developer) you can't.

[bluedino]

> This design has the really annoying situation that applications closing down can't leave stuff in the clipboard.

Some programs on Windows will present you with this dialog when closing the program:

There is a large amount of information on the Clipboard. Do you want to be able to paste this information into another program later?

[mzs]

lots results when I google 'wayland clipboard manager' - here's the first

https://github.com/yory8/clipman

[tinalumfoil]

That's an unfortunate list of known issues.