Atomic ets

[Ulf Wiger]

Den 2005-12-20 20:38:08 skrev Matthias Lang <matthias@REDACTED>:

>
>  Robert>>> If your application uses ets as a communication mechanism
>  Robert>>> between processes, that is surely quite a sore design mistake.
>
>  Ulf> Note the wording "ets as a communication mechanism"
>
>  Matthias> inet_db,
>
>  > I have a fair idea of what most of these do, and
>  > I don't think any of them use ets as a communication
>  > mechanism, but rather as an internal storage structure.
>
> You're most likely correct: it doesn't quite fit Robbie's description.
>
> But it's just as pretty: an "internal storage structure" which
> happens to be publically writeable and named, just ready for someone
> to, um, communicate with it.

Yes, even though not all of those tables are publicly
writeable:

2> I = fun(T,A) -> ets:info(T,A) end.
#Fun<erl_eval.12.2225172>
3> IL = fun(T,As) -> [I(T,A) || A <- As] end.
#Fun<erl_eval.12.2225172>
4> [{T,IL(T,[name,named_table,protection])} || T <- ets:all()].
[{global_names_ext,[global_names_ext,true, protected]},
  {global_locks,    [global_locks,    true, protected]},
  {global_names,    [global_names,    true, protected]},
  {ac_tab,          [ac_tab,          true, public]},
  {inet_db,         [inet_db,         true, public]},
  {inet_hosts,      [inet_hosts,      true, public]},
  {file_io_servers, [file_io_servers, true, protected]},
  {inet_cache,      [inet_cache,      true, public]},
  {11,              [shell_records,   false,public]},
  {10,              [code_names,      false,private]},
  {9,               [code,            false,private]}]
5>

It's not obvious to me why e.g. ac_tab should be public.
All updates to the table, except one, are done from the
application_controller process, and it seems as if the
insertion of the {sync_dacs, ok} object from the dist_ac
process is merely a way of piggy-backing on the
application_controller table. This particular object
is also used as a sort of semaphor for the permit_application
functionality(*) (which, with 20-20 hindsight, should never
have been included in the first place.)

If we ever get an application_controller overhaul,
at least I vote for excluding permit_application
entirely. And if any of you out there are using it,
please don't.  (:

So I agree - when using ets, one is often tempted to make
the code 'dirtier' than it needs to be, while using
functional data structures tends to impose some modicum
of discipline on the programmer (if nothing else, because
the opportunities to mess things up are more limited.)

/Uffe

(*) In other words, I was mistaken.

-- 
Ulf Wiger