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: Rob McKeever <email@hidden>
- Date: Fri, 2 Apr 2004 09:09:42 -0800
Justin,
That's exactly what's going on... and I do have a fair bit of
synchronization logic in place to handle the thread sync issues. The
problem is that the sorwakeup (same might be true for the matching
sowwakeup) call doesn't reliably exit the state machine for the socket
recv call.
...Part of my problem here has been tracing the calls internally to try
to figure out what goes where, given the dynamic nature of the TCP
stack, but I now have sorted out. Just trying to figure out the
best/most reliable way to abort the state machine for that socket
without corrupting too much of it's state in the process...
-Rob
On 1-Apr-04, at 10:00 PM, Justin Walker wrote:
>
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.
>
>
>
>
End of darwin-kernel Digest
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.