[erlang-questions] erlang port and C executable

[Michael McDaniel]

On Sun, Nov 23, 2008 at 08:31:42PM +0100, Per Hedeland wrote:
> "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
_______________________________________________


 Though not addressing all the questions above, here's an old
 post from me regarding how I'm using open_port and killing the
 spawned process ...


 http://www.trapexit.org/forum/viewtopic.php?p=30762&highlight=&sid=0cce5d6ad7c14306754ec99249fe912f


 I use the technique to monitor a USB port.


 In the original post I forgot to include the command I use to echo back
 the PID;

 I get the PID using my port/0 command ...

-define(IF, "/dev/ttyUSB0").
-define(DD, "/bin/dd if=" ++ ?IF ++ " bs=1 oflag=dsync& pid=$!; echo $pid").

port() ->
   Port = open_port({spawn, ?DD },
		    [eof, exit_status, use_stdio, binary]) ,

   receive
     {Portb, {data, Pid_with_lf}} ->
     {ok, Pid_of_dd, 1} = regexp:gsub(binary_to_list(Pid_with_lf), "\n", "")
   end ,

   io:fwrite('~p~n', [{Portb, {data, Pid_with_lf}}]) ,

   {Port, Pid_of_dd}
.


~Michael


-- 
Michael McDaniel
Portland, Oregon, USA
http://autosys.us