shared data

[utzoo!decvax!ucbvax!unix-wizards]

>From dsp.dove at MIT-SPEECH@MIT-AI Sun Nov  1 16:09:46 1981
	I don't see why a dispatch vector would be worth it.  The
loader would have to be hacked to provide info about sharing anyway.
Also several kernel mods would have to be made to map apr's.

	The main problem I used to have is that all progs had the
shared data in the same virtual address (the code wasn't pic).  This
meant that if several shared segments were contemplated one could be
in the bind of choosing which to use.  Also, because the address
binding was done so early, any change to the shared library required
the users to recompile everything.  A vax would eliminate the virtual
address contention problem probably, but getting unix to make pic
would be hard I expect.

	By shared data, I meant a scheme whereby a file represented a
shared data area (as it does for text) and users could perform a sys call
to allocate some aprs to map a portion of it.  A given segment of the file
would be locked in memory (perhaps the whole thing, but that would limit
its usefulness) as long as any proc had it referenced, and that would be
done in a similar way to text locking.  Finally, unlike text, when the data
was swapped out, it would have to be written to the file.

	All this would in addition require some semaphore mechanism to
permit controlled access, but that part would be fairly simple.

	This means of interprocess communication would be mainly for
handling enourmous common database problems that want to be fast, and
to allow things like array processing on 11's (provided the entire data
file need not be resident).

	Myron Zimmerman should be credited with this idea  (unless someone
has already done it).
-------