First of all, thanks to all who answered.
I have carefully read all of the answers and I'm trying to figure out
some points now:
1. What events?
I can't see somewhere a list of events, for which upcall function
will be invoked.
Unfortunately ADC documentation seems to be incomplete (see
"Your upcall function will be called when:" is the last line in
I have downloaded xnu-1228.3.13 and I'm looking it through now.
2. Blocking vs. non-blocking?
Josh Graessley wrote:
> The only difference between blocking and non-blocking is that
blocking will block and wait if there is no space available in the
Frankly speaking it is a surprise for me, I supposed that write
function for blocking socket returns only when an operation (sending)
is actually completed.
Anyway, I suppose blocking does not work for me.
I'm writing a driver that process read / write routines from a
file system context, so I think blocking can be dangerous here.
Network Kernel Extensions Programming Guide says here:
If your code is in a performance-critical part of the kernel (as
opposed to a call from user space), you should generally perform
socket I/O asynchronously.
Moreover I think mbuf part of code must be non-blocking too
(according to this document).
3. If I get EWOULDBLOCK status from sock_sendmbuf?
What does EWOULDBLOCK status of send operation exactly means?
At the moment I suppose it means that there are no enough memory
in send buffer.
So I just should retry later, yes?
I can use blocking sockets in a separate thread anyhow.
Is using blocking sockets with an upcall function correct in general?
5. Should I get to know when a send operation actually completes?
I think a general answer is no.
When sock_sendmbuf returns I should think that the operation is done.
First invoking of the upcall routine is related to sock_connect
(no matter blocking or non-blocking).
Then I should try to read at any upcall.
Am I right?
The ADC example
does not free mbuf in the upcall routine.
Is this a bug or a special case (related to upcall)?
Sorry for so long message,
Thank you very much for reading it.
Please correct me if I'm wrong somewhere.
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