[575] in SIPB bug reports
xscreensaver doesn't close the X socket when execing programs
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sun Jun 11 18:03:55 1989
Date: Sun, 11 Jun 89 18:05:53 -0400
From: Jonathan I. Kamens <jik@Athena.MIT.EDU>
To: raeburn@ATHENA.MIT.EDU
Cc: jtkohl@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Ken Raeburn's message of Thu, 1 Jun 89 09:44:07 EDT <8906011344.AA14282@PROMETHEUS.MIT.EDU>
Date: Thu, 1 Jun 89 09:44:07 EDT
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
xscreensaver should set close-on-exec on the X socket.
I would claim that the X library should be responsible for doing this
in the name of defensive programming, and have so claimed in bug
reports to the X consortium. After some arguing back and forth, they
are going to consider it.
I've had this argument with Chris Peterson, as well. When I first was
writing the code to do lock commands, unlock commands, etc., I did
both an XtCloseDisplay and an XCloseDisplay after doing the fork
before exec'ing the process. It didn't help -- the xscreensaver still
hung around if the child processes didn't die.
I very strongly hesitate about setting close-on-exec on the X socket.
This breaks abstraction barriers all over the place, and (I think)
won't work on all dialects of Unix that can compile xscreensaver,
besides. Since xscreensaver is a toolkit program, it's not even
supposed to know what an X socket IS, so it should definitely be the
toolkit's job to fix this.
If you still want me to (and remind me) try to find a solution to this
when I get back in the fall, I will do so. It's really hard to debug
X programs on an Apple ][+. :-)
jik
