Den Wednesday 06 May 2009 05.03.32 skrev Nathaniel Smith:
> On Tue, May 5, 2009 at 7:39 PM, Ethan Blanton <[email protected]> wrote:
> > Nathaniel Smith spake unto us the following wisdom:
> >> On Tue, May 5, 2009 at 6:31 PM, Ethan Blanton <[email protected]> wrote:
> >> > ... with WM_CLIENT_MACHINE passed through transparently. This seems
> >> > the most appropriate course of action. I'm not even convinced the
> >> > (via xpra) should be there.
> >>
> >> The one downside to that is that WM_CLIENT_MACHINE may be used for
> >> other purposes as well, e.g.:
> >>
> >> http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#KILLINGWINDOWS
> >
> > I don't see the problem, what am I missing?
>
> If the xpra client goes off to la-la land, then modern WMs will
> notice, and pop up a "hey, this app is unresponsive, do you want to
> kill it?" dialog. And if you click "yes", then it'll actually kill the
> app (not just disconnect it from the X server and leave it spinning in
> the background and silently chewing all your cpu, no matter how
> traditional that is, hi netscape 4). But this only works if
> WM_CLIENT_MACHINE indicates that it's on the same host and kill(2)
> will work.
<!> Warning of (possibly) way too much public thinking, you could skip to the
"Hmm..."-paragraph if you're allergic too "thinking-while-typing" texts.</!>
What happens when one uses xkill on a window?
I'm thinking that, since xpra is a sort of screen for x perhaps we should do
things in a similar way. I think the equivalent screen scenario is screen
going crazy and one kills the terminal window. Screen has a configurable
behaviour on "hangup":
-----------------------------------------------------------------------------
8.1 Detach
==========
-- Command: autodetach state
(none)
Sets whether `screen' will automatically detach upon hangup, which
saves all your running programs until they are resumed with a
`screen -r' command. When turned off, a hangup signal will
terminate `screen' and all the processes it contains. Autodetach is
on by default.
-----------------------------------------------------------------------------
Source: info screen -> Session Management -> Power Detach
(<http://os.cqu.edu.au/cgi-bin/info/info2html.cgi?(screen)Detach> if you don't
have info or the info-pages for screen installed)
So, to reconnect to xpra:
the hangup is (afaik SIGHUP) sort of equivalent to what ever is send as window
message to a X window when xkill'ed (I'm assuming it's the same as what
happens when the app is unresponsive and the WM suggests killing it).
So, without knowing how xkill works, would it be possible to have xkill'ing a
"xpra window" configurable to mean either:
* "just kill the xpra client, and leave the actual program running"
* or "kill the xpra client and the wrapped program".
I.e. assume xpra crashed vs. assuming the program crashed.
This option could be stored in $HOME/.xpra/xprarc (with system default
/etc/xprarc), similar to screen's screenrc (but with the exception that the
user configurable settings are stored in $HOME/.xpra/xprarc instead of
$HOME/.xprarc (since we already have a $HOME/.xpra it seems better to keep the
rc there). Alternately, use invocation arguments for this (to the client or
server).
Then the question from where this option makes sense to implement. Should it
be the xpra client or server that decides what happens? Let's think of what
scenarios may happen:
(client = the real program, xpra-client = the xpra client)
* client crashes, xpra-client lives
* client lives, xpra-client crashes
* client crashes, xpra-client crashes
Does the server have any idea what happens when the xpra-client dies? (i.e. is
the connection stateful or connection less (cf. TCP vs UDP))
If the server is aware of the xpra client dying it would make most sense to
let the server decide what happens. I'm guessing the server could even send
the ping mentioned in the URL you linked to (the wm-spec) to tell if the
client actually crashed or not - this is where the "what to do on hangup"
would make sense, should the server _assume_ that the client crashed and
terminate it, or should it _assume_ it's just busy and will deal with X
messages later (i.e. badly designed app/non-threaded).
In an ideal world the server would magically know if the client truly is alive
(but busy) or dead and take action based on that. But I think the best we can
do is assume, and to avoid making an "_ass_ of _u_ and _me_" (pun probably
lost in text mode ;) too often leaving the users with at least having
something to say about the default assumption/behaviour.
I.e. if the user thinks xpra is more stable than the app or not - or at least
giving more deterministic behaviour of the BadThingsHappening™-feature.
Hmm... (reading what I just wrote) I think I've just thought a little too much
now, putting a warning beacon before it ;)
Basically what I think now is that: killing the xpra window forcefully should
kill the xpra connection, and then the server should decide if the client
program should be killed too or not (by "wm pinging" it). A "non forced
shutdown" would leave the client running (i.e. the xpra client quitting and
the connection being closed isn't a surprise to the server).
I come to think of a new scenario, network timeout, in this case we'd want the
client to keep on living and with the suggestion above it would - since the
client would still respond to ping. The problem might be the client still
thinking it's connected to the xpra server. Otoh, if using TCP (or other
stateful connection types) it would know that the connection made a timeout
too thanks to the nature of TCP -- making it a non-issue, but something to
take in to account if using stateless connections.
Cheers and my 2 $str_coin_denominator coins :)
/Fredrik
> This is a bit of a finicky detail, though, and of course, xpra
> contains no bugs, so this will never come up.
>
> I'm not sure if there are any other non-cosmetic uses of
> WM_CLIENT_MACHINE... there could be in principle, but maybe not in
> practice.
>
> -- Nathaniel
>
> _______________________________________________
> Parti-discuss mailing list
> [email protected]
> http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
--
After all, if you are in school to study computer science, then a professor
saying "use this proprietary software to learn computer science" is the
same as English professor handing you a copy of Shakespeare and saying
"use this book to learn Shakespeare without opening the book itself."
-- Bradley Kuhn
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
