Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!bbn!mit-eddie!uw-beaver!rice!sun-spots-request
From: david@sun.com (Are we controlled by secret forces?)
Newsgroups: comp.sys.sun
Subject: Re: selection_svc
Keywords: Windows
Message-ID: <3626@kalliope.rice.edu>
Date: 26 May 89 18:47:24 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 12, message 4 of 15

In article <8905091802.AA29608@SunWS5.rulcs.uucp> you write:
>X-Sun-Spots-Digest: Volume 7, Issue 285, message 9 of 10
>
>As mentioned in SunSpots v7n194, the selection_svc program hangs around
>after exitting suntools. Since I started some experiments with customised
>suntools executables this has become a major nuiscance, since installing a
>new /usr/bin/suntools (late at night) invariably leads to swapping errors
>(the next morning, in client selection_svc's which I forgot to kill)....

Please note that this is not a good idea if any of your users run multiple
suntools processes (on machines with multiple frame buffers or cg4s).  All
the tools will be using the first selection service started; if you kill
it off along with one suntools process, the tools on the other desktop(s)
will have no selection service.  It can be very hard to recover from this.

Why don't you just rename the old suntools process to "suntools-" before
installing the new one?  You could also make selection_svc a separate
non-merged binary.  I doubt that there are many pages shared between it
and other toolmerge processes.

[[ A selection_svc running as another user is also a security hole (or so
I've been told).  --wnl ]]