how to kill a port's external process?

[Chris Pressey]

"Garrett G. Hodgson" wrote:
> i'm building a little gui wrapper around a command line audio player.
> i've got an erlang process that calls open_port() to spawn the external
> player, but it doesn't actually send/receive anything to it over stdio.

I don't think the port mechanism was ever intended to be used that way
:)

The Interoperability Tutorial says:

| 4.1 Erlang Program
|    First of al,l communication between Erlang and C must be
|    established by creating the port. The Erlang process which
|    creates a port is said to be the connected process of the port. All
|    communication to and from the port should go via the connected
|    process. If the connected process terminates, so will the port
|    (and the external program, if it is written correctly).
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^

Further down on that page there is example C source:

/* port.c */

     typedef unsigned char byte;

     int main() {
       int fn, arg, res;
       byte buf[100];

       while (read_cmd(buf) > 0) {
         fn = buf[0];
         arg = buf[1];
         
         if (fn == 1) {
           res = foo(arg);
         } else if (buf[0] == 2) {
           res = bar(arg);
         }

         buf[0] = res;
         write_cmd(buf, 1);
       }
     }

So the port terminates when the read_cmd() function detects end-of-file
from the Erlang side of things (AFAICT.)

Do you have the source to the external program?  It might help to
rewrite the main body to listen to the Erlang ports mechanism, even if
there's no established interface.

> so, is there a clean way to kill this beast?  i can think of some kludgey
> ways, like gathering the output of ps and constructing a unix command to
> kill it.  but it seems like there ought to be a better way?  can someone
> point me in the right direction?

This goes beyond Erlang, but... killing a process based on the name
of a program is always dodgy at best, given that a program can change
what it shows up as in 'ps'.  A better way is to use DJB's daemontools,
which, IIRC, opens up one pipe per process, giving you a truly unique
handle to it.

> Garry Hodgson                   And when they offer
> Senior Hacker                    golden apples
> garry@REDACTED                are you sure you'll refuse?
> Software Innovation Services    Heaven help the fool.
> AT&T Labs

Kallisti :)

Chris

-- 
This sentence is false.