sticky bit
glen herrmannsfeldt
where static data could be shared among different executions
of the same program?
It might be that, for the feature I am considering, that it
is supposed to share read only code segments, but that with
the right options one can also share data.
I thought I was remembering this from unix, but it
might be TOPS-10.
-- glen
Eric Smith
> Does TOPS-10 have a feature, similar to the unix 'sticky bit'
> where static data could be shared among different executions
> of the same program?
That's not the Unix "sticky bit", but in any case, under TOPS-10
if you put the static data into the high segment, it is normally
shared. You have to go out of your way to NOT share the high
segment.
Eric
Mark Crispin
On TOPS-20, you have to go out of your way to NOT share any page that
hasn't been written. There's no need for a "high segment" on TOPS-20
(although programs built that way will work fine); pages are normally
copy-on-write.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
glen herrmannsfeldt
(snip)
> On TOPS-20, you have to go out of your way to NOT share any page that
> hasn't been written. There's no need for a "high segment" on TOPS-20
> (although programs built that way will work fine); pages are normally
> copy-on-write.
The one I am trying to remember doesn't do copy-on-write
so you can share writable data between different tasks.
(For example, high scores in a game.)
It might be misusing a feature designed for read only data,
or it might be designed to work that way. I am remembering
it from TOPS-10 days, which is why it might be TOPS-10
that I am thinking of.
Can a TOPS-10 shared high segment be writable?
-- glen
Mark Crispin
> The one I am trying to remember doesn't do copy-on-write
> so you can share writable data between different tasks.
Yes, a trick well-known and used in the days before IPCF.
> It might be misusing a feature designed for read only data,
> or it might be designed to work that way. I am remembering
> it from TOPS-10 days, which is why it might be TOPS-10
> that I am thinking of.
> Can a TOPS-10 shared high segment be writable?
Yes. It's the SETUWP UUO. TOPS-10 also has the "meddle bit" which
prevents the use of that UUO if the hiseg is something that you shouldn't
be meddling with. Failure to set the meddle bit when needed was the cause
of numerous TOPS-10 security bugs.
Johnny Billquist
Huh? I thought that was the definition of the Unix "sticky bit".
From the man-page:
The ISVTX (the sticky bit) indicates to the system which executable files
are shareable (the default) and the system maintains the program text of
the files in the swap area. The sticky bit may only be set by the super
user on shareable executable files.
Anyway, RSX can also share read-only parts of programs. You just need to link
it, telling it that the program should be used that way.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
jmfbahciv
There are all kinds of ways to share static data on the -10.
ARe you positive it's static?
/BAH
glen herrmannsfeldt
(snip)
> There are all kinds of ways to share static data on the -10.
> ARe you positive it's static?
Fortran 66 assumes about static data.
Fortran 77 allows local variables to be either static
or automatic. COMMON is still pretty much static.
There was discussion on porting gcc to the -10, which
should include gfortran. A Fortran 95 or 2003 compiler
on the PDP-10 would be interesting. Then the data
might not be static.
-- glen
Pat Farrell
> Fortran 66 assumes about static data.
> Fortran 77 allows local variables to be either static
> or automatic. COMMON is still pretty much static.
COMMON was static? on F10? or just F77.
I never did much with F77 on KLs
But we mangled common all the time. It was the mark of a real Fortran
programmer to stuff two small integers into a longer word as you went
from routine to routine. Source of many bugs as well
--
Pat Farrell
http://www.pfarrell.com/
titan
a) never refered to shared data only shared text (aka executable code)
b) did not imply not-shared! ie wasnt a reference to sharing.
It was a reference to the OS to lock the executable pages from
joining the free list
that way they would be either perminantly in memory or on the
swap device so as near to ready to use as could be. Just an efficiency
not a share/noshare flag.
Thats as it was things have change some what to the point that nobody
cares to mark executables that way.
a) we have so much bandwidth for CPU/MEM/DISK that nobody cares if ls
is sticky
b) even with out stickly modern UNIX tries very hard to be efficent
about this, so much so that you will see a RE statistic recording the
activicty of REattaching pages from the free list. When you run a
program eg /bin/ls for the first time the pages get maped by a pager
direct to the backing store of the program "/bin/ls" (executables
dont swap to the system swap device).
Then via the OS, ls is page faulted as needed into memory. The code
exits and he pages fall onto the free list, but seconds later another
exec request references /bin/ls the OS finds the pages still on the
free list and pulls them back from there, ls executes and maybe finds
all of its needed pages still in physical memory. This is quite
efficient and much more fine grained that stick bits on the file.
c) the only current useful meaning of sticky bit is now in reference
to a directory where t bit now changes the security features of the
directory such that the permissions on the file now matter not the
permissions to the directory. Many sane operating systems the
permissions on the file mean everything ie if its say you cant delete/
replace it then thats it. In UNIX however the read/write permission of
the parent directory control this except when the directory has t bit
(sticky) set.
Hopefully that clarifies the sticky bit
Johnny Billquist
From the man-page for the sticky bits history section in NetBSD - sticky(7):
HISTORY
The sticky bit first appeared in V7, and this manual page appeared in
section 8. Its initial use was to mark sharable executables that were
frequently used so that they would stay in swap after the process exited.
Sharable executables were compiled in a special way so their text and
read-only data could be shared amongst processes. vi(1) and sh(1) were
such executables. This is where the term ``sticky'' comes from - the
program would stick around in swap, and it would not have to be fetched
again from the file system. Of course as long as there was a copy in the
swap area, the file was marked busy so it could not be overwritten. On
V7 this meant that the file could not be removed either, because busy
executables could not be removed, but this restriction was lifted in BSD
releases.
But today, the sticky bit is not used for files, and is only meaningful for
directories, yes.
Johnny
titan skrev:
glen herrmannsfeldt
> No. This is incorrect. The sticky bit indicated both shared text and data.
> From the man-page for the sticky bits history section in NetBSD -
> sticky(7):
> HISTORY
> The sticky bit first appeared in V7, and this manual page appeared in
> section 8. Its initial use was to mark sharable executables that were
> frequently used so that they would stay in swap after the process exited.
> Sharable executables were compiled in a special way so their text and
> read-only data could be shared amongst processes.
(snip)
OK, but my question was about sharing writable data, either legally
or by telling the OS that it was read only but writing anyway.
I presume in modern OS that swap from the executable file those
pages are copy-on-write such that anything written is not shared.
That may not have been true in early unix, though.
-- glen
jmfbahciv
> jmfbahciv wrote:
> (snip)
>
>> There are all kinds of ways to share static data on the -10.
>> ARe you positive it's static?
>
> Fortran 66 assumes about static data.
> Fortran 77 allows local variables to be either static
> or automatic. COMMON is still pretty much static.
My mind is boggling. Are you able to give an example of
this data? I still have no idea what you want.
>
> There was discussion on porting gcc to the -10, which
> should include gfortran. A Fortran 95 or 2003 compiler
> on the PDP-10 would be interesting. Then the data
> might not be static.
>
What data? Compiler data; fortran program data; file data;
system data; network data; user data;
Is it a date-time stamp?
If I knew the kind of data and what you mean by "static"
I could tell you three different ways to keep/access it.
/BAH
Johnny Billquist
> Johnny Billquist wrote:
>> No. This is incorrect. The sticky bit indicated both shared text and
>> data.
>
>> From the man-page for the sticky bits history section in NetBSD -
>> sticky(7):
>
>> HISTORY
>> The sticky bit first appeared in V7, and this manual page appeared in
>> section 8. Its initial use was to mark sharable executables that were
>> frequently used so that they would stay in swap after the process
>> exited.
>> Sharable executables were compiled in a special way so their text and
>> read-only data could be shared amongst processes.
> (snip)
>
> OK, but my question was about sharing writable data, either legally
> or by telling the OS that it was read only but writing anyway.
True. And Unix didn't do that with the sticky bit.
> I presume in modern OS that swap from the executable file those
> pages are copy-on-write such that anything written is not shared.
> That may not have been true in early unix, though.
In the early Unixes, you didn't even share "private" data before you wrote to
it. You always had your own copy, even if it was unmodified.
Unix and shared memory have a somewhat weak history.
Unfortunately I can't answer on TOPS-10, but I think others have.
For RSX, there are no problems at all creating shared memory objects. Both
read-only and read-write, as well as shared instruction areas.
But that was not what you asked about either. :-)
Johnny
Eric Smith
> Huh? I thought that was the definition of the Unix "sticky bit".
> From the man-page:
>
> The ISVTX (the sticky bit) indicates to the system which executable files
> are shareable (the default) and the system maintains the program text of
> the files in the swap area. The sticky bit may only be set by the super
> user on shareable executable files.
Hmmm... on my system it appears that all executables do that, and it says
that the sticky bit on executables is obsolete but used to make them "stick"
in memory even after the use count dropped to zero.
In recent times, I've only seen the sticky bit used on directories, where
it means something entirely different.
Johnny Billquist
Well, yes. It's ratherhistoric rather than current usage... I should probably
have posted more in that first quote.