Atomic ets

[Mats Cronqvist]

Robert Virding wrote:
> 
> I think you will find when you get down to it that a magical new API 
> probably won't be much more efficient as it basically still has to do 
> the same work. Even if you don't SEE it.
> 
> One of the original tenants of Erlang was that distribution could be 
> transparent when desired, message passing and error handling were 
> designed to be transparently distributable. I can think of better things 
> to do than to add a general distributed transaction system to Erlang. 
> And to add one to the basic language that only worked localy would be a 
> Bad Thing and would probably mean that the poor users will not only 
> shoot themselves in the foot but also chop off the whole leg. At the 
> very best.

   i've been mulling over the above for a while now, and i don't get it.

the original question in the thread was this:
 > Are there simple,
 > useful ways to write ets code that avoids the problem of
 > getting preempted between, say, a lookup and an insert?

   more generally, what do you do if you you need to make sure your erlang 
process is not scheduled out between two BIF calls. i think the answer is; 
"write a new BIF"(*). see e.g erlang:spawn_link/3;

    spawn_link(Module, Function, ArgumentList)

    This BIF is identical to the following code being evaluated in an atomic
    operation:

    > Pid = spawn(Module, Function, ArgumentList),
      link(Pid),
      Pid.

    This BIF is necessary since the process created might run immediately and
    fail before link/1 is called.

or ets:insert_new/2, which is basically an atomic version of;

case ets:loopkup(Tab,Key) of
   [] -> ets:insert(Tab,{Key,Val});
   _ -> false
end

   in an atomic block spawn_link could be implemented like this;
atomic
   link(Pid = spawn(Module, Function, ArgumentList))
end

   i'm not sure what "general distributed transaction system" has to do with any 
of this.

   mats

(*) in some cases, such as in the original question, you can serialize through a 
server (which will slow you down some).
   sometimes i've resorted to this nasty hack;

erlang:yield(),
foo(),
bla().

   which'll (probably) make foo and bla atomic (at least as long as the vm uses 
reduction counting)