Interrupting passive socket recv

[Chandrashekhar Mullaparthi]

Another suggestion would be to make gen_tcp:recv take a message pattern
which it should send back to the controlling process. In R6B, the call to
gen_tcp:recv ends in this function:

call(S, Request) ->
    Tag = make_ref(),
    Pid = S#socket.pid,
    Pid ! {call, self(), Tag, Request},
    receive
        {Tag, Reply} -> Reply;
        {'EXIT', Pid, Reason} ->
            {error, closed};
        {tcp_closed, S} ->
            {error, closed}
    end.           

Now if this is extended to:

call(S, Request, MyPattern) ->
    Tag = make_ref(),
    Pid = S#socket.pid,
    Pid ! {call, self(), Tag, Request},
    receive
        {Tag, Reply} -> Reply;
        {'EXIT', Pid, Reason} ->
            {error, closed};
        {tcp_closed, S} ->
            {error, closed};
	  {MyPattern, Mesg} ->                       
		{MyPattern, Mesg}
    end.       

So I can call:
gen_tcp:recv(SocketRef, Length, my_message) so that all messages to my
process in the format {my_message, Something} are given to me as a result.

This is pretty restrictive in the sense that your messages have to conform
to a certain structure, you can specify only one pattern....
Multiple/Arbitrary patterns can be specified if clause guards are extended
to take a user defined fun. In that case, the above function can be written
as:

call(S, Request, UserDefinedPredicateFun) ->
    Tag = make_ref(),
    Pid = S#socket.pid,
    Pid ! {call, self(), Tag, Request},
    receive
        {Tag, Reply} -> Reply;
        {'EXIT', Pid, Reason} ->
            {error, closed};
        {tcp_closed, S} ->
            {error, closed};
	  Message when UserDefinedPredicateFun(Message) -> Message
    end.           

cheers,
Chandru

> -----Original Message-----
> From: Sean Hinde [mailto:Sean.Hinde@REDACTED]
> Sent: 14 November 2000 12:04
> To: 'Peter Andersson'
> Cc: 'Erlang Questions'
> Subject: RE: Interrupting passive socket recv
> 
> 
> Peter,
> 
> > Just a few thoughts... What if you spawn a separate process 
> > just to handle the
> > receiving of TCP messages? To avoid flooding this process (in 
> 
> Yes, I also thought a bit about this solution. The drawback is that it
> introduces an extra message transfer as the recv process will 
> have to send
> the replies back to my marshalling process which knows who 
> asked the query
> and so can return the answer to the right place.
> 
> Killing the recv process is also a bit nasty as well, though 
> it does raise
> the additional question of how one interrupts a 
> gen_tcp:accept. This is an
> issue for code upgrades as well as a general programming 
> issue. The options
> seem to be the same as documented for recv - timeout and 
> retry to allow
> space for other Erlang messages to be received - which is 
> pretty horrible
> (lost connections)
> 
> Any more tricks up anyones sleeve for this one?
> 
> Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.