[erlang-questions] erlang port and C executable

Edwin Fine erlang-questions_efine@REDACTED
Sun Nov 23 20:44:21 CET 2008

> >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.

Thanks for the offer, but it's working correctly NOW. I did post the C and
Erlang code (that is, the code that works) in this thread; if you are bored
sometime and want to critique it, I'd appreciate it. The symptom was that
the spawned echo program was not closing down. I now think that what
happened is that it got input and was trying to write output, but the Erlang
port closed before it could do that, so it was hung on the output pipe. When
I did a flush() in the shell later I got more input than I expected, so
maybe that was it. I was only whining a bit about how sometimes getting
things to work in Erlang seems like "magic" to people like me who are not
familiar with every corner of Erlang, and obvious to gurus like you and
Johnny. Then I feel a bit stupid.

> 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 see the point now, thanks.

> >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.

So it's not actually that trivial ;)

> 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.

Those are all excellent points. My desire would be for a wrapper that allows
one to reliably start, stop, and exchange data via stdin and stdout with a
Unix/Linux program such as gnuplot. I have done this in Ruby before to chart
performance data (rrdtool did not fit my needs) and IMHO it is a heaven-sent
ability. Maybe I should try to write such a wrapper myself and see what is
involved. If it's any good, hey, maybe I can put it on trapexit....

Thanks for your help and advice.

> --Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081123/3d37a168/attachment.htm>

More information about the erlang-questions mailing list