Atomic ets

[Vlad Dumitrescu XX (LN/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of 
> Thomas Lindgren

> Yes, but if you funnel all writes to a table through a 
> server, you "lock the whole table" to, say, update a single 
> entry. I would prefer a more concurrent solution when table 
> operations are common. 

Hi,

Please correct me if I'm wrong, but when just updating a row there
shouldn't be a big problem since this "lock" is held just briefly. It's
possible that most clients won't notice it (this is true for a single
CPU, where there's just one execution context running at a given time
anyway, right?).

Where the problem would be more visible is when doing many/bulk updates
to only one part of a table, while others might need to read from
unrelated parts. 

This brings up a (mad?) vision: if Erlang processes had internal threads
(or in a equivalent view, several processes shared state), then one
could only "lock part of a table" for each one of those. 

Hmmm, what a can of worms... ;-)

/Vlad