Interrupting passive socket recv

[Sean Hinde]

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.