Interrupting passive socket recv

[Peter Andersson]

Hi Sean,

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 case your main
application doesn't request the data quickly enough), the socket should be in
passive mode. Your main application process will have normal response times
since it is the separate process that does the waiting if nothing comes in over
the socket. The protocol between the main process and the receiving one must, of
course, be asynchronous. If you need to abort the gen_tcp:recv() then perhaps
you can just kill the separate process. I don't know if this is a possible
workaround. I guess it depends mainly on the behaviour of your application.
Synchronisation between different events, like multiple TCP receives, should
still be possible even if the main process communicates asynchronously with the
"workers".

Regards

  /Peter


Sean Hinde wrote:
> 
> Trying to be as precise as possible about an idea, here goes:
> 
> I'm thinking about an application in which my Erlang node might get flooded
> with replies to a query it has sent over a socket.
> 
> This situation would appear to lend itself to a passive gen_tcp:recv/2 call
> rather than an active socket so that the message buffer doesn't chew up all
> the memory of my machine while it tries to deal with the flood.
> 
> The problem with passive recv is that as far as I can make out the only way
> to make the process waiting in recv state look at Erlang messages is to time
> out the recv every so often (every few millsecs to make it responsive) and
> call receive. This would appear to be pretty inefficient.
> 
> It would be very nice to have some setup (either in the socket library, or
> as an extra to the normal Erlang receive?) where a rec{v | eive} with
> *passive* semantics could return either a packet or an Erlang message.
> 
> So EITHER:
> 
> An enhancement to the active socket mode where the part of a virtual
> "message buffer" holding excess tcp/ip packets is held out at the far end of
> the socket rather than filling the local Erlang message buffer.
> 
> OR
> 
> An enhancement to gen_tcp:recv where the recv can be interrupted on receipt
> of an Erlang message
> 
> I'd be very interested to hear of any ways others have found to get around
> this problem efficiently, and if not, I'd like to propose something like it
> as an enhancement to OTP.
> 
> - 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.