Actually it meant the "text" segment (code and constant
data) was
write-protected during execution, and hence could be shared between
multiple processes executing the same program. In fact that's why it was
called the "sticky" bit -- the text segment could stick in RAM even if
the process was swapped out, and in fact never needed to be swapped out
because it could always be reloaded from the executable file. This is
now assumed in the case of modern paging systems, but in the old PDP-11
it wasn't available on all models and could in some corner cases reduce
the total amount of virtual memory available to the process (you only
had a total of 8 physical segments of up to 32Kb each, and the stack
took up at least 1; later models allowed 16 segments total but 8 could
only be text and 8 could only be data or stack). Hence it had to be
user-modifiable.
[although you needed a later 2.x BSD to utilise anything beyond 64K code
64K data. 2BSD could do segment handling stuff [think DOS EMS and try not
to get flashbacks from the horror]
Now I'm showing my age :-)
The V7 manual doesn't quite agree with you. The sticky bit simply
indicates that the code segment for the binary should be kept around in
memory/swap (fast storage) not discarded. It might get set on a tiny
number of root apps to tune performance.
Anyone who remembers "resident" on the Amiga has the right idea.
It did require on the 11 that the program was split I/D so there was an
unmodifiable code segment but that's an implementation detail for that
architecture. Some Unixen today still honour the sticky bit for
executables - but not many.
As it was only relevant for executables it also got borrowed for other
bits. For directories it indicates that only the file owner can
unlink(remove) files - mostly to fix /tmp. A couple of systems use
it for other 'magic' on non-executable files.
Alan