Re: Object sharing between processes

Janis Dzerins wrote:
> Peter Minten wrote:
>  >
>  > I was wondering about how Lisp objects can be safely shared in a
>  > hypothetical Movitz LispOS[1]. The problem is the following shell
>  > script:
>  >
>  > (bar (foo))
>  >
>  > Say foo and bar are both programs, not functions. Foo gives something
>  > as output which becomes bar's input. Now I see two problems with a
>  > each-process-an-address-space system:
> 
> I don't quite understand what you mean by "are both programs, not
> functions"!  What is a program in LispOS?  And "shell scripts"!? I think
> other questions may get answered or disappear when we deal with this
> one...

Hmm, good point. I think one can define a program as a function that runs in 
another process. On the other hand one could also think of stored functions 
running in the current process instead of separate programs.

I think shell scripting in MILOS (to give the thing a name for now) consists 
mainly of loading stored functions (in fast-load files) into the current process 
and using them, but sometimes you'll want to run a function in a different 
thread. Traditionally this is solved by heavyweight threads (processes) and 
lightweight threads (threads), but given enough flexibility in the threading 
system of Movitz I can imagine the difference fading.

If the treading system is able to create threads that have only limited access 
to the global and special state of their creators, it's possible to pretty 
securely use stored functions without having to fear the mess up the spawning 
program.

This would effectively mean you'd get processes, but more powerful since they 
can share some global state with their parent thread.

On a related note I think that shell scripting in MILOS will not be different 
from writing a program. For example this is how a simple script could look like:

(uselib "text") ;if not loaded load and use
(format t "~&Word count of file /data/foo = ~A.~%" (wc $/data/foo))
(write *standard-output* ($/bin/ls $/data))

Here you can see two ways of using stored functions. In the wc form the function 
comes from the text lib which is explicitely loaded at the start of the script. 
In the ls form the ls function is stored on disk, but since it's used in a 
function context it's automatically loaded and used. The wc form is more 
efficient if used often (loaded once, instead of ls which can be loaded every 
time it's used), but the ls form allows better quick-and-dirty scripting. The 
$... is a reader macro that expands into (file ...) to make it easy to work with 
files in a script.

Greetings,

Peter