Alter the r1.35 of event.c race fix. Remove the forward looking event

queue check (removing the need for a server grab/ungrab) - if the client
is going away, let it fall all the way through to a DestroyNotify event.
There's no longer a need for us to manually destroy a client ourselves
(removing yet another server grab/ungrab).  Instead, when the
UnmapNotify event is synthetic, simply set the state to Withdrawn (as
per ICCCM), else Iconic (in our case 'hidden').

Verified with test case from the 2009 race which was the original reason
for r1.35 of event.c.

1 files changed, 2 insertions, 11 deletions

diff --git a/client.c b/client.c
index 9d448fd..fadbc18 100644
--- a/client.c
+++ b/client.c
@@ -15,7 +15,7 @@
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  *
- * $OpenBSD: client.c,v 1.148 2013/11/11 12:51:15 okan Exp $
+ * $OpenBSD: client.c,v 1.149 2013/11/12 21:25:00 okan Exp $
  */
 
 #include <sys/param.h>
@@ -149,20 +149,11 @@ client_init(Window win, struct screen_ctx *sc, int mapped)
 }
 
 void
-client_delete(struct client_ctx *cc, int destroy)
+client_delete(struct client_ctx *cc)
 {
 	struct screen_ctx	*sc = cc->sc;
 	struct winname		*wn;
 
-	if (destroy) {
-		XGrabServer(X_Dpy);
-		cc->state = WithdrawnState;
-		xu_set_wm_state(cc->win, cc->state);
-		XRemoveFromSaveSet(X_Dpy, cc->win);
-		XSync(X_Dpy, False);
-		XUngrabServer(X_Dpy);
-	}
-
 	TAILQ_REMOVE(&sc->mruq, cc, mru_entry);
 	TAILQ_REMOVE(&Clientq, cc, entry);