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

[Serge Aleynikov]

Thanks for the suggestion, I'll take a look at the odbc code.

Supervisor_bridge behavior is what I am currently using to ensure proper 
cleanup of the managed port and other resources.

Serge

Ingela Anderton Andin wrote:
> 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
>