[erlang-questions] Using select in a Port

[Per Hedeland]

jm <jeffm@REDACTED> wrote:
>
>Per Hedeland wrote:
>
>>>>> Is the port owner process still running? The port gets automatically
>>>>> closed when the owner exits.
>> 
>> I.e. I'm referring to the Erlang process that opened the port (unless
>> you have changed the port owner with e.g. port_connect/2). That process
>> exiting is the most likely cause of the port getting closed from the
>> Erlang side. Possibly the port could also be closed by the runtime if
>> you have specifed some more "advanced" "protocol" than
>> stream/packet/line and the incoming data doesn't follow it (any random
>> data can be interpreted as being either of those three), but in that
>> case the port owner should get an exit signal.
>
>
>The erlang process which owns the port dies.

So there you have it, now you just need to figure out *why* it dies -
no need to try low-level port I/O debugging for that.

> I've checked to see that I 
>didn't do something so that it's not tail recursive and it seems 
>correct. Also checked to make sure I wasn't doing something stupid like 
>printing debug info to stdout, checked that all messages sent to erlang 
>are generated by ei and sent using write_cmd.

This is sort-of irrelevant - if the port was closed by the VM "for some
reason", your process would get an exit signal that might kill it, but
since you're trapping exits it won't. And forget what I wrote about
"advanced protocols", there aren't any for an external-process port
(temporary synapse crosstalk delivered some inet driver functionality) -
i.e. the data that arrives on such a port from the outside can never be
"wrong" from the VM's point of view.

I can however be wrong from your process' point of view - e.g. if it
expects to receive binaries in Erlang external term format, and
optimistically does a binary_to_term/1 on whatever it gets, it will die
with a badarg if your port program sends garbage - and the port will be
closed *as a result of your process dying*. At least during debugging
you may want to wrap catch and/or try around such things. And at least
when running from the shell, you should get a message about the
immediate cause of any "unnatural" death:

=ERROR REPORT==== 25-Oct-2007::22:30:11 ===
Error in process <0.52.0> with exit value: {badarg,[{erlang,binary_to_term,[<<3 bytes>>]},{ll,loop,1}]}


--Per