Usage of BIF port_control/3?

Ulf Wiger <>
Mon Feb 28 11:57:39 CET 2000


> From: Scott Lystig Fritchie <>
> To: 
> Subject: Re: Usage of BIF port_control/3? 
> Date: Mon, 28 Feb 2000 02:31:51 -0600
> 
> Gack!  I wanted to include something else in my last message.  {sigh}
> My colleagues joke that I live in Hawaii's time zone, not Minnesota's,
> but I guess it's getting late.
> 
> The reason for my experimentation is that I'm working on a project
> where, under high workloads, inet:sockname/1 appears to block forever.
> It doesn't make much sense, but it's happening.  (Stuck in
> inet:call/2.)  

Scott, 

There are problems in inet.erl, and the OTP group is working on 
a fix. We have encountered similar problems. Our mail exchange with
support was in Swedish, but basically:

>From inet.erl:

256: call(Socket, Request) when record(Socket, socket) ->
257:     Tag = make_ref(),
258:     Pid = Socket#socket.pid,
259:     Pid ! {call, self(), Tag, Request},
260:     receive
261:        {Tag, Reply} -> Reply;
262:        {'EXIT', Pid, Reason} ->
263:            {error, closed};
264:        {tcp_closed, Socket} ->
265:            {error, closed};
266:        {udp_closed, Socket} ->
267:            {error, closed}
268:     end.

Since there is neither a timeout nor a monitor on the socket
process. The controlling process is linked to the socket process
but any other process trying to talk to the socket may hang forever.
Unless you have the very latest patch (don't even know if there is one
for Open Source Erlang yet -- we use commercial OTP R5B), you
may run into this problem.

There are other problems as well, for example in gen_tcp.erl:

controlling_process(S, NewOwner) when record(S,socket),pid(NewOwner) ->
    case call(S, {set_owner, NewOwner}) of
        ok -> 
            sync_input(S, NewOwner),
            S#socket.pid ! {commit_owner, NewOwner},
            receive
                {owner, NewOwner} -> ok
            end;
        Error -> Error
    end.

The receiver of the {commit_owner, NewOwner} message links itself
to the process calling controlling_process/2, so if the socket
pid has died, there will be an infinite wait (no link, monitor,
or timeout guarding the dialog.)

Perhaps your problems with inet are of this nature?

/Uffe

Ulf Wiger, Chief Designer AXD 301         <>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44




More information about the erlang-questions mailing list