On Oct 3, 2007, at 9:55 AM, Brian Bergstrand wrote:
On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote:
I have modified the tcplognke example and it was pleasant sailing
until now. I am sending packets to userspace that are about 2020
bytes long. Userspace reads each packet and responds with a
setsockopt() call with a 2k structure.
When a burst of packets gets sent, some packets will fail to be
received by user space but no error was indicated from
ctl_enqueuedata()
Calling ctl_getenqueuespace(), the packets end up disappearing
when ever the queuespace is not the maximum. Bumping up the
socket recvbuf from 8k to 60k did not help one bit!
ut otherwise the packets would just disappear when ever the
enqueuespace was not at max.
This is how control sockets work. Here's a way to get around the
problem (if you can gracefully sleep that is):
int retry = 3;
retry_data:
size_t recvsz = 0;
if (0 == ctl_getenqueuespace(ctl_ref, ctlunit,
&recvsz)
&& recvsz < datasize && retry > 0) {
// msg q is full
// Sleep one quantum giving the client a
chance to wake
struct timespec ts = {0, 10000000};
(void)msleep(NULL, NULL, PSOCK,
__FUNCTION__, &ts);
retry--;
goto retry_data;
}
err = ctl_enqueuedata(...);
Please don't do this. If you're running on the input thread you're
going to hurt network performance.
-josh
Well, for me, this code is in a separate thread not involved in the
network stack. But if we aren't supposed to do this in a network
callback (which again, I'm not doing) what are we supposed to do? As
Karl pointed out, ctl_enquedata doesn't handle this case itself, so
we have to.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/email@hidden
