[rdtsc]

> ETS is not a process that responds to messages, you have to wrap it in a process and do the messages part yourself.

I didn't say it's implemented as a process but works as if it where logically. Most terms (except literals and the binary references) are still copied just like when you send message. You could replace it behind the scenes with a process and it would act the same. Performance-wise it won't be the same, and that's why they are implemented differently but it doesn't allow sharing a process heap and you don't have to do locks and mutexes to protect access to this "shared" data.

> i am pretty sure that's a process_info bif that directly queries the vm internal database and not a secret message that can be trapped or even uses the normal message passing system.

I specifically meant querying the dictionary of another process. Since it's in the context of "erlang is violating the shared nothing" comment. In that case if we look at https://www.erlang.org/doc/system/ref_man_processes.html#rec... we see that process_info_request is a signal. A process is sent a signal, and then it gets its dictionary entries and replies (note the difference between messages and signals there).

[dnautics]

ah sorry you did indeed write signal and somehow my brain read it as "message". I'll stand by my ets comments though because it would be confusing to think of ets as not having to be wrapped in a process (for lifetimes if nothing else)

[rdtsc]

> I'll stand by my ets comments though because it would be confusing to think of ets as not having to be wrapped in a process (for lifetimes if nothing else)

The point was that "ets" doesn't break isolation and doesn't logically behave any differently than as if inside it was wrapping a process and every lookup or update was behind the scenes sending a message to the process to read its data and returning a response. So the original poster's claim that somehow defaults to "sharing memory" are simply untrue. They just don't understand how it works, which is fine. I suspect they don't really use it that much and just found whatever they could by Googling it (pun intended as they are a Technical Program Manager).

Also, here is Robert Virding, one of Erlang creators, explaining it a lot better https://stackoverflow.com/a/1483875:

> ETS more or less behaves as if the table was in a separate process and requests are messages sent to that process. While it is not implemented with processes that the properties of ETS are modeled like that. It is in fact possible to implement ETS with processes. This means that the side effect properties are consistent with the rest of Erlang.