[movitz-devel] Object sharing between processes

[mikel evins]

On May 5, 2004, at 9:33 PM, James A. Crippen wrote:

> mikel evins <mikel at evins.net> writes:
>
>> Note, though, that there are some handy features of non-LISP operating
>> systems that we would probably like to have (certainly, that I would
>> like to have).
>
> Definitely. There's been a lot of innovation in the past fifteen
> years. Things like 3D support, user interfaces, filesystems,
> networking, and the like. All should be designed from a modern
> perspective, not just as a slavish recreation of the old LispM
> designs.

I posted a couple of messages along these lines a little while back. If 
you look at Plan 9 you can see a particularly elegant realization of 
the Unixy way of thinking about systems. What I want to think about is: 
what is the equivalent lispy way of thinking about systems? Plan 9's 
great organizing principles are files and a uniform hierarchical 
namespace. What are the corresponding leveling abstractions of a Lisp 
OS? Closures? Trees? Streams? What?

>
>> One of them that I would certainly like to have is some sort of
>> support for security; Symbolics and other LispM systems were quite
>> insecure, by design. Anyone could frob anything in any process
>> anywhere at any time, which was certainly very handy when developing
>> software, but it's not so great when you want to have a system that
>> lives on the net or otherwise shares resources with users and
>> processes that may not necessarily be trustworthy.
>
> Hear hear! It should be possible, of course, for random processes to
> poke at each other, but only if the user really wants it to be this
> way. Normally they shouldn't be able to.
>
> Interprocess communication in Unix and similar systems is awful. It's
> awful because the processes have no 'insecure' way of poking at each
> other without the crock that is shared memory, or the ugliness of
> pipes, et sim. If processes are allowed to poke at each other without
> restriction, or at least easily through well defined interfaces, then
> the person doing IPC gets a big win. However, it's still necessary
> nowadays for processes to be somewhat protected from each other. Thus
> I envision some sort of ACL like thing that could be part of a plist
> in each stack group and accessible globally.
>
> A lot of attention needs to be paid to how threading systems are
> implemented in existing Lisps. Also some good examination needs to be
> written on multiprocessing on Lispms so that people who don't happen
> to own one can learn how it works.
>

It's instructive to read about the Eros implementations of persistence 
and capabilities. There are actually some kind of tricky aspects to 
getting ACLs to work right, and those guys have spent several years on 
it now.

--me