Re: terminating a socket read from inside the kernel
Re: terminating a socket read from inside the kernel
- Subject: Re: terminating a socket read from inside the kernel
- From: Justin Walker <email@hidden>
- Date: Thu, 1 Apr 2004 11:28:39 -0800
On Apr 1, 2004, at 10:44, Rob McKeever wrote:
Hi Justin,
By abort I mean abandon the pending read or recv call on the socket
without closing the connection. The receive runs on a separate thread
and I can send that thread a signal via pthread_kill() to kick it back
out of the system call. What I was trying to accomplish via the
sorwakeup() call was to roust the kernel thread out of the read/recv
call in much the same fashion - I'm probably missing some small but
important bit about setting the state of the socket state machine, etc.
I'm not entirely sure I understand what you are doing, so forgive me if
this sounds overly simplistic.
You have several (>= 1) threads running in the kernel, one of which is
awaiting incoming bits. You want to tell that thread to knock it off
and get on with other work.
The way this is normally done is with something like a semaphore. The
simplest approach is to have a "KnockItOff" variable that is normally
zero. Your read thread checks it before it goes off in a read, to see
whether the read should be avoided. Another mechanism can set this to
1, and then call sorwakeup(). On awakening, your original thread goes
through its normal "getting ready to read" logic, discovers that a
higher authority wants it to belay that, and does as requested.
In a kernel environment, you are running in a preemptive threading
world, of course, so you will need some additional baggage to assure
that the "check variable; sleep" sequence is atomic (so that the
variable doesn't get set and the wakeup sent prior to the sleep
occuring).
Under the current regime, given that you are in NetworkWorld, the
Network Funnel is your friend. The thread that sets the bit will have
to hold the funnel while it sets. Your read thread will automatically
have the thread (when it runs) since it is readING a socket.
In the TomorrowLand, when the KPI and other changes arise, you will
need to revisit the mechanism you use for synchronization.
Hope that helps. Let us know if I missed the point.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | It's not whether you win or
lose...
| It's whether *I* win or lose.
*--------------------------------------*-------------------------------*
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.