RE: Asynchronous sock_sendmbuf
RE: Asynchronous sock_sendmbuf
- Subject: RE: Asynchronous sock_sendmbuf
- From: "Eddy Quicksall" <email@hidden>
- Date: Thu, 22 May 2008 13:51:36 -0400
I'm using non-blocking / upcall because (1) it is more efficient than
switching threads and (2) I only need one thread for all connections (and 3,
it is an embedded application and not much memory is available for lots of
threads).
Eddy
-----Original Message-----
From: darwin-kernel-bounces+quicksall_temp=email@hidden
[mailto:darwin-kernel-bounces+quicksall_temp=email@hidden]
On Behalf Of Terry Lambert
Sent: Wednesday, May 21, 2008 7:31 PM
To: Igor Mikushkin
Cc: email@hidden
Subject: Re: Asynchronous sock_sendmbuf
On May 21, 2008, at 3:30 AM, Igor Mikushkin wrote:
> 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.
This is to prevent you from blocking on a write, and having everything
pile up behind you waiting for you. For example, if your KEXT is a
block device driver that does network based logging, then blocking on
logging is going to prevent anything talking to your block device
driver from talking to the media while you are busy waiting for the
logging to occur.
It's perfectly reasonable to marshall the I/O off to another thread,
and have it make a blocking call on your behalf, so long as you don't
depend on the call having been made for subsequent operations to be
successful
-
Maybe we can step back a second...
What are you trying to accomplish here that you think getting an
upcall would accomplish for you?
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
uth.net
This email sent to email@hidden
_______________________________________________
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