[4779] in Athena Bugs
problems w/Xlib, xscreensaver ...
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Tue Apr 17 13:56:11 1990
Date: Tue, 17 Apr 90 13:55:56 -0400
From: Ken Raeburn <Raeburn@MIT.Edu>
To: bugs@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
Which version of X11 was the current SIPB xscreensaver on the pmax
built with?
If it's X11R3, then the screensaver should set the close-on-exec flag
on the X file descriptor, as should any other sensible X program that
will fork and exec other programs. There is a bug in the X library,
in that it does not do so. If the parent is killed off, the windows
stay up and -- if keyboard and mouse are grabbed -- control is not
returned until the child is killed.
If it's X11R4, then consider this a bug report to the effect that the
X library still has this problem.
When I reported it under X11R3, I was told it wasn't a bug, doing
otherwise would be undocumented behavior, etc. I don't buy this. To
me, the principle of least surprise says that only the process that
talks to the X server should have the file descriptor open. There is
no reasonable way a program being exec'ed could make use of the file
descriptor, and it could easily disrupt communications between the
parent and the X server.
In this particular case, my screensaver was failing to receive
keyboard input (and I'm using mwm); I logged in remotely and killed
it, but I didn't get control of my screen back until I found the zaway
process it had spawned and killed that as well. This is foolish.
