Shared memory proposal

[Dmi]

Hi, Lutz!



Last time I study Erlang and I found a useful thing that, imho, can significant simplify the newlisp asynchronous tasks when we need to fork and to use semaphores/shared memory.



I think it would be cool to have some engine over shared memory when one process can issue

Code Select Expand

(send-message Pid message)
to send a regular newlisp value to the shared-memory queue of forked process Pid.

and other process can issue

Code Select Expand

(receive-message) -> (Sender_Pid Message)
to receive next message from it's queue.



Probably, some blocking/non-blocking options etc. may be applicable here



The Erlang's version of this is much more powerful, but highly related to Erlang features.

But I think, that even this level of messaging will be more user-friendly and human-error free than concurent access to shared memory.

[Jeff]

receive-message would want to take a call-back function as its final argument.

[Lutz]

I like the idea and have put it high on my to do list for the post 10.0 version releases. Distributed and multi processing has always been of high interest for newLISP and will continue to evolve.

[newdep]

Yes this wil eventualy result in shared remote memory array's over tcp ;-)

[Dmi]

Lutz: Wow! This would be nice!

newdep: No! Please! ;-)