[erlang-questions] If you could rename ports, what would you call them?

[Joe Armstrong]

On Wed, Oct 6, 2010 at 2:14 AM, Jeff Schultz <jws@REDACTED> wrote:
> On Tue, Oct 05, 2010 at 05:04:18PM +0200, Joe Armstrong wrote:
>> There should be the notion of "creating a thing that behaves like a
>> process" that is actually not a process, which which behaves like a
>> process. Ets tables and ports should have been "things that behave
>> like processes" - they should respond to messages and send exits
>> when they die and so on. If they had behaved like processes then
>> life would be easier and more regular ... If ports where pids then
>> one would be able to access ports on remote nodes via their pids
>> (just like remote pids in distributed erlang).
>
> This sounds good to me, but I have a practical question:
>
>    How much existing code would break if ets:new or open_port
>    returned a pid?  Is there a lot, or very little?
>
> Your protocol/1 idea would make it easy to adapt is_port to only
> succeed on pids created by open_port, but there's probably code
> somewhere that handles both ordinary processes and ports and that
> distinguishes them by is_pid.

The more I think about this the more I like it.

The problem with a Pid is you have no ideas what resource it represents and
what protocol it obeys - this information is conveyed implicitly by
the location of the Pid
in some bit of code - you need to say "hello pid, which protocol do you obey"
this cannot result in a network message but must be local to a pid.

You need to know this information *before* you send a message, thus
the implementation
cannot involve any messaging. I think the Pid is just a heap pointer
to a local data
structure, so adding an extra field would be no bother ...

You could use process_info(Pid) and look at the initial_call data
but I assume process_info results in a network message to find out
what's up with the
process (is this correct?)

>
>
> For that matter, what would we do with the named_table option to
> ets:new?  Make it register the process?

But there shouldn't be named tables at all - there should only be pids
and registerd processes
one name registration mechanism not many ...

>
>
>    Jeff Schultz
>