Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!ucdavis!csusac!unify!Unify.com!grp
From: grp@Unify.com (Greg Pasquariello)
Newsgroups: comp.windows.x
Subject: Re: window manager swapping (was Re: Another R5 wish)
Message-ID: <1990Sep26.091300@Unify.com>
Date: 26 Sep 90 16:13:00 GMT
References: <235@grapevine.EBay.Sun.COM> <9009041636.AA23617@hansen.com> <489@zok.UUCP>
Sender: news@Unify.Com (news admin)
Reply-To: grp@Unify.com (Greg Pasquariello)
Organization: Unify Corporation, Sacramento, CA, USA
Lines: 37

In article <489@zok.UUCP>, mark@zok.UUCP (Mark W. Snitily) writes:
> In article <9009041636.AA23617@hansen.com> jim@ncd.COM (Jim Fulton) writes:
> >
> >    When I move the
> >    mouse pointer from an active xterm window to one of the swapped-out 
> >    windows and start typing, input goes to the window that I WAS on until 
> >    the new window comes in from disk.
> >

[ Some stuff deleted...]

> Having seen this query (with the same answer) a number of times, I'm
> surprised the suggestion of turning the window manager's "sticky" bit on
> hasn't been mentioned.
> 
[ Some more stuff deleted...]
> 
> Quoting from the man page:
>     "If an executable file is set up for  sharing  (this  is  the
>      default)  then  mode 01000 (save text image after execution)
>      prevents the system from abandoning the swap-space image  of
>      the program-text portion of the file when its last user ter-
>      minates."
> 
> In other words, it won't get swapped out.  The con is that it'll always
> be there, but you'd probably want to keep the window manager in memory
> anyway.

Setting the sticky bit doesn't prevent swapping.  It simply saves the process
image in swap space after the process terminates, so that subsequent
invocations
don't have to reload from scratch.

> 
> -- Mark
---
-Greg Pasquariello	grp@unify.com