Merge lp:~smspillaz/xig/xig.disconnect-signals into lp:xig
Proposed by
Sam Spilsbury
Status: | Work in progress |
---|---|
Proposed branch: | lp:~smspillaz/xig/xig.disconnect-signals |
Merge into: | lp:xig |
Prerequisite: | lp:~smspillaz/xig/xig.clean-up-after-clients |
Diff against target: |
43 lines (+26/-0) 1 file modified
src/xig-server.c (+26/-0) |
To merge this branch: | bzr merge lp:~smspillaz/xig/xig.disconnect-signals |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Ancell | Needs Fixing | ||
Review via email: mp+89535@code.launchpad.net |
Description of the change
Disconnect signals the remote client is interested in when it goes away.
To post a comment you must log in.
Unmerged revisions
- 256. By Sam Spilsbury
-
Disconnect stale signals too to avoid a race where the signals are dispatched
after the remote client is unrefd - 255. By Sam Spilsbury
-
Clean up after clients - remove stale resource id's and selections. Also
handle the edge case where clients die and leave stuff behind. - 254. By Sam Spilsbury
-
Write message length according to format, not actual length as that's too much
From me via IRC:
"What you really should do is the server should connected to the destroyed signal for the resources and remove them that way
so you're explicitly destroying the references from both sides, but the server should be implicitly destroying them
(or the other way around). The patch has both the server and client responsible which is dangerous if one of them gets out of sync.
So there's two ways we can do this - the client destroys itself, and the server detects that and destroys all its resources, or the client destroys all its resources then itself, and the server doesn't care"
and Sam said "So I think the best way to handle this is to have a XigClientResource which XigSelection and XigDrawable inherit"
Which is correct.