On Tue, Dec 28, 2010 at 07:11:31PM -0800, Bryan O'Sullivan wrote:

On Tue, Dec 28, 2010 at 3:49 PM, Simon Horman wrote:

...

One issue that has come up is that recvBufFrom calls getpeername() for each successful recvfrom(). This is unnecessary in the context of the code that I am working with as the result is discarded.

The network library is maintained by Johan, so you'd be best off talking to him directly. He's already doing a major rewrite of the library, so this is a good time to be bringing your question up :-)

Thanks, I'll get in touch with him off-list if he doesn't reply to this thread.

On Wed, Dec 29, 2010 at 06:39:37PM +0100, Johan Tibell wrote:

On Wed, Dec 29, 2010 at 12:49 AM, Simon Horman wrote:

...

My proposed solution to this is to implement recvBuf.  For the sake of symmetry I think that it it would also make sense to add sendBuf, although I don't have any performance-based reasons for this.

I do intend to add recvBuf (perhaps as recvInto). I'm not so sure about sendBuf as it can be implemented with almost no performance cost by wrapping a ByteString constructor around a buffer.

...

Before preparing patches - I have a crude one for testing that works - I would like to get an idea of if this change acceptable or not. And if so discuss which API calls might be appropriate to add.

I'd prefer if you just added Network.Socket.recvBuf for now, against the current HEAD.

Sure, I will prepare a patch.