[erlang-questions] port_close/1 problem (Serge Aleynikov)
Thu Nov 1 14:08:32 CET 2007
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.
Ingela Anderton Andin wrote:
> 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
> 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
More information about the erlang-questions