shared memory in Erlang
Scott Lystig Fritchie
Tue Jan 30 23:34:48 CET 2001
>>>>> "dg" == David Gould <> writes:
dg> On Tue, Jan 30, 2001 at 09:12:44PM +0100, Karel Van Oudheusden wrote:
>> Are there Erlang compilers that support shared memory between
If you mean between Erlang processes, the Binary data type is as close
as you can currently get.
ETS tables can be used by multiple processes (if created as a 'public'
or 'protected' table), but its implementation makes copies of
dg> I am having trouble picturing it fitting in without a great deal
dg> of collateral damage...
Assuming a "process" in this context is a UNIX, not Erlang,
I've dabbled with a hack that had all binary storage allocated from a
shared memory segment. A new BIF would spit out the address and
length of a binary. That address and size could be given to another
UNIX process which had also mapped that memory region in the same
Heh. "Collateral damage" is a good phrase. There are several big
problems with this hack.
1. Erlang's automatic memory management can reclaim a binary's memory
and re-use it for something else, *before* the other UNIX process
retrieved the data it wants from the shared memory buffer. A hack was
to have an Erlang server process keep a reference to that binary, and
when the other UNIX process was done with the shared memory buffer, it
would signal back to the Erlang server to unreference the binary.
2. The Erlang VM was the sole owner of the shared memory region. No
other UNIX process could allocate memory within it. To do otherwise
was a good way to crash the VM.
3. An external UNIX process could violate Erlang's immutable data
property: it could modify the contents of a binary object. This was
half the reason for this hack in the first place, but it void's the
Erlang warranty. :-) (Performance, by eliminating data copying, was
the other reason.)
I did that hack probably a year ago. I haven't returned to it, due to
collater^Wsheer ugliness. Every now and then Ithink of it. But a few
random thoughts every 6 months isn't enough to cook up reasonable
semantics for this kind of thing, much less try to implement them.
More information about the erlang-questions