Atomic ets

[Mats Cronqvist]

Ulf Wiger wrote:
> Den 2005-12-14 20:29:03 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:
> 
>> 5. Introduce a magical new API more suited for
>> concurrent/atomic ets. Drawback: it doesn't exist yet
>> :-)
> 
> 
> You'd think that with a functional language, there
> should be a way to write code that is verifiably
> 'shallow' (no loops, no side effects - or, in this
> case, only allowed side effects). This is essentially,
> what we want for the match specifications (replacing
> the ms_transform module), for mnesia transactions
> (where the manual kindly asks us to write pure code)
> and perhaps for atomic ets. If a function could be
> tagged as (conditionally) safe, one could offer an
> 'atomic' construct and have it execute only such
> code.
> 
> /Uffe (who volunteers _not_ to be the one implementing it.)


   perhaps a few times a year i'm faced with problems where serializing, locking 
or (especially) mnesia are noticably slowing the code down. for those 
situations, i would be happy for the possibility to run any code in the "magical 
new API", even though it is potentially risky.
   of course, it'd be better if the compiler would enforce that i could only 
call bif's in the critical section (that would make is pretty safe i guess).

   mats