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

[Joe Armstrong]

On Fri, Oct 8, 2010 at 12:18 PM, Kresten Krab Thorup <krab@REDACTED> wrote:
> Further to this discussion, I would love to see a way that would allow writing a "port driver" in erlang.  It would be a case to consider to make the resulting abstractions be more orthogonal to one another.
>

Indeed - in fact the Erlang scheduler and GC should be written in Erlang
- this would have to be a strictly controlled sub-set of Erlang that created no
garbage and had access to memory and registers - something that could
be cross compiled to C (do pretty much like they did in smalltalk many
years ago :-)

/Joe

> For instance, with just a handful of NIFs you could implement the tcp_ip driver in erlang, and the result would likely be much more readable and manageable (but perhaps not so performant).  You could actually do such an implementation now of course, but it would not work with port-specific functions like port_info, etc...
>
> Kresten
>
>
> On Oct 6, 2010, at 9:53 , Joe Armstrong wrote:
>
>> 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
>>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
> Kresten Krab Thorup, CTO, Trifork
>
>