[erlang-questions] port_close/1 problem

[Per Hedeland]

Serge Aleynikov <saleyn@REDACTED> wrote:
>
>I reread this email and realized that I forgot to mention the fact that 
>in my understanding port_close/1 merely closes its end of the pipe used 
>to communicate with the port process.

Correct - i.e. there are no signals sent.

>  So in this case if the running 
>port program is in the middle of a blocking call it won't detect the 
>closing of the file descriptor it uses to communicate with Erlang and 
>will continue running.  So if I wanted to kill that port by sending an 
>appropriate signal from Erlang how can I determine the OS pid of the port?
>
>The obvious answer is to communicate that OS pid back to Erlang through 
>the pipe, but in this particular case it takes over two to three minutes 
>before the port loads all components and starts reading its end of the 
>pipe, and I'd like to be able to kill it prior to that.

Hm, but after it has done that loading, this "3rd party binary
interpreter" will actually start communicating with Erlang on fd 3/4,
using {packet, 2} format? I guess not, i.e. you probably have some
wrapper around it - and if so, can't you send the pid from the wrapper
code *before* doing all the loading?

Alternatively, you could experiment with something along the lines of

 {spawn, Exe ++ " & echo $!"}

That obviously won't work as-is with {packet, 2}, so it has to be a bit
more complex, and the backgrounding *might* mess up the pipe plumbing,
but I don't really think it should.

--Per Hedeland