Proposal to add recvBuf and sendTo to Network.Socket
horms at verge.net.au
Wed Dec 29 00:49:07 CET 2010
recently I have been looking into a latency-gap between the
C and Haskell implementations of a TCP-echo
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.
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 have not yet considered what changes to the higher-level Network API
would make sense in order allow getpeername-less recv and read.
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.
More information about the Libraries