Re: Asynchronous sock_sendmbuf
Re: Asynchronous sock_sendmbuf
- Subject: Re: Asynchronous sock_sendmbuf
- From: Josh Graessley <email@hidden>
- Date: Tue, 20 May 2008 09:41:53 -0700
On May 20, 2008, at 9:27 AM, Eddy Quicksall wrote:
#define SO_NWRITE 0x1024 /* APPLE: Get number of
bytes currently in send socket buffer */
Are you saying I would wait for an up_call that shows no bytes left
in the buffer? If so, what about the bytes that have not yet been
moved from my user buffers to the mbuf's?
You will receive no up_calls related to the send side of your socket.
This socket option will give you the number of bytes currently in use
in the send buffer. You can get the send buffer size SO_RCVBUF and
subtract the number of bytes returned by SO_NWRITE to determine how
much space is left in the send buffer. If you're trying to figure out
when all of the bytes have been sent (and acked), you can wait for
SO_NWRITE to reach zero. Again, because there is no upcall for send
buffer related events, your only option is to poll (a horrible option).
It would probably be safe to consider the so_send complete after all
bytes have been transferred to the internal buffers but this does
not seem to give me that information.
In that case, you're done when when so_send or so_sendmbuf returns.
The only difference between blocking and non-blocking is that blocking
will block and wait if there is no space available in the send queue.
Another question: If I have back-to-back asynchronous calls to
so_send will they all be transmitted?
Yes.
The problem with not getting an upcall related to the send side is
that you can fill the send buffer. If you fill the send buffer and are
using a non-blocking socket, subsequent calls to sock_send will return
EWOULDBLOCK I believe. Ideally, you would get an upcall to let you
know when the send buffer has more space available. Instead, for now,
you either have to use another thread and do blocking calls or
periodically poll the socket to determine when there is space
available for writing.
-josh
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden