Xpra: Ticket #896: get rid of daemon threads

As per Python Exception in thread Thread-1 (most likely raised during interpreter shutdown)?, we should not be using daemon threads and should just ask them to exit cleanly during the cleanup phase.

Thu, 25 Jun 2015 10:42:53 GMT - Antoine Martin: status, milestone changed

status changed from new to assigned
milestone changed from 0.17 to 0.16

r9698 prepares for the change
r9700 changes all but the network IO threads to non-daemon mode
r9701 debugging tweaks and attempts to set socket to non-blocking (unfortunately, this does not affect the in progress recv call..)

Mostly there - only the two network threads can end up not exiting due to blocking IO calls.

(somewhat similar to #873)

Fri, 26 Jun 2015 10:13:57 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to alas
status changed from assigned to new

Server fixes and improvements:

The changes above could cause the server to get stuck on control-C, because the main loop is no longer running and we relied on it to cause the encode threads to exit. This is fixed in r9711 - (may get backported).
r9710 also dumps all the threads still running during the server cleanup (with -d server) - there should only be network IO threads left (and the main thread)
r9714 should ensure we always eventually force_disconnect the connections if they haven't cleaned themselves up following the disconnect_protocol

@afarr: this is just a FYI - feel free to close as an ACK. If I've done this wrong, it may be possible for the server to get stuck and not exit when we tell it to:

via control-C
via kill -SIGINT $THESERVERPID
via xpra exit or xpra shutdown
when the server exits because of settings like exit-with-client or exit-with-children

It just makes the code more correct and robust, and may avoid some of the exceptions that can appear during shutdown (like #873).

Mon, 06 Jul 2015 15:25:01 GMT - Antoine Martin:

Another ticket that keeps on giving... more fixes in r9851 + r9852.

(and also some more cosmetic improvements in r9849)

Wed, 29 Jul 2015 23:18:57 GMT - alas:

Tried with fedora 20 & 21 servers, 0.15.4 r9951, r10082, r10133 ... control-c, kill -15 PID, and a simple xpra stop :DISPLAY. Everything closed as expected, servers re-started smoothly.

Trying xpra exit, however, the server indicated it had shutdown, but when trying to start again it failed due to an unknown session at :DISPLAY... and I had to kill the Xorg PID to clean the display up.

As for xpra shutdown, I couldn't figure out the syntax for it. The wiki seems to indicate it's a client sent message, but I couldn't figure out how to send from the client, and it wasn't a recognized control channel message.

Thu, 30 Jul 2015 00:56:09 GMT - Antoine Martin: status changed; resolution set

status changed from new to closed
resolution set to fixed

Trying xpra exit, however, the server indicated it had shutdown, but when trying to start again it failed due to an unknown session at :DISPLAY... and I had to kill the Xorg PID to clean the display up.

That's because it is exactly what it does. See the manual: This command attaches to a running xpra server, and requests that it terminates immediately. Unlike xpra stop, the Xvfb process and its X11 clients (if any) will be left running.

After using this command, you can start a new xpra server against the display it left behind using the --use-display command line argument.

As for xpra shutdown, I couldn't figure out the syntax for it.

There is no such command, I meant "stop". (there is an internal command called 'shutdown' which is the one used by "stop")

Closing.

Sat, 23 Jan 2021 05:09:07 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/896