[erlang-questions] port_close/1 problem (Serge Aleynikov)

[Ingela Anderton Andin]

Hi!

A suggestion is to solve this little problem the way that the 
odbc-port-program does.
The odbc port-program has two threads one supervisor thread and one 
thread that does
the actual work.  Both  threads set up an ordinary socket to the erlang 
process and then
communicates through them. The supervisor thread waits for a message 
from erlang and
if it gets it it will exit the c-process. So the erlang process can at 
any time for any reason it sees fit
terminate the c-process. Of course there are other reasons why  the odbc 
port-program does want to use sockets and not at all use the pipe to 
communicate with erlang, except initially. (These are not relevant here,
let me just say it has to do with handling all sorts of ill behaved 
odbc-drivers)

Another suggestion could be to try to use the supervisor_bridge 
functionality, I have never had the chance
to use it in reality so I have no hands on knowledge of it, but it could 
be worth considering.

Regards Ingela  - OTP team

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