[erlang-questions] erlang port and C executable

[Per Hedeland]

"Edwin Fine" <erlang-questions_efine@REDACTED> wrote:
>
>On Sun, Nov 23, 2008 at 11:57 AM, Per Hedeland <per@REDACTED> wrote:
>
>> "Edwin Fine" <erlang-questions_efine@REDACTED> wrote:
>> >
>> > One of the most annoying aspects is that under
>> >circumstances that are not clear to me, the C program that is spawned
>> >sometimes does not seem to be sent a signal for end of file when you close
>> >the port, so if it is reading stdin, it's just going to sit there until
>> >killed manually.
>>
>> This should never happen - i.e. there is no "signal" for end of file,
>> it's just the result of reading when there is nothing more to read - but
>> a port program that actually reads its stdin should always get end of
>> file when the port is closed (after having read what there is to read,
>> if anything). "You're probably doing something wrong."
>
>
>You're probably right. But nothing wrong in the C program, I don't think.
>That's why I found it a bit frustrating to get the Erlang program working
>correctly.

If you can provide code that doesn't get the EOF (and tell us what you
do with it:-), we should be able to point out what you're doing wrong.

>> > Worse, if it gets stuck doing something and is NOT reading
>> >stdin then you are out of luck.
>>
>> This is expected, and can be considered a feature - it allows you to
>> e.g. start a daemon that *should* keep running after you close the port.
>>
>
>There are well-known techniques to starting daemons that don't rely on open
>ports

OK, s/daemon/long-running program/. Johnny's comment was to the point,
closing the port just means "I don't want to talk to you anymore", it
doesn't mean "die now".

>I understand - I was pointing more to the idea than the implementation. I
>think Erlang/OTP should perhaps provide a standard wrapper C program that
>will run any program as a child, and has a back-channel that allows you to
>kill it (and its child) if the child becomes non-responsive.

Perhaps, but they can't do everything for you - it's a trivial program
to write, except that there's a lot of little things that it should do
in different ways depending on your needs, which means that it will
become quite complex to use if it should cover everyone's needs.
E.g. does it need to "proxy" input and/or output for the child program?
Should it grab its stdio for this or use some other file descriptors?
What "protocol" should it talk on the port pipes back to Erlang? Etc.

--Per