Hi Michael, in working on socket NKEs, I've found "TCP/IP Illustrated, Vol 2" by Wright & Stevens to be a great help, in addition to Stevens's other books. There's a section in there on interrupt levels and concurrency. This deals with BSD in general, rather than OS X in particular. The same general rules apply though because otherwise the whole stack would be failing. The splnet(), splx() etc routines in their original BSD implementation managed concurrency by controlling interrupt levels. As has been noted, this is insufficient for MP systems. On OS X, they are calls into the funnel mechanism and no longer work by adjusting interrupt levels. Note that there are no levels - the network lock is an all-or-nothing lock. The kernel lock is similar. And you can't hold both of them, only one or the other. You'll also see code which switches between, starting out with kernel lock and switching to network lock when dealing with network structures. The code for processing ioctls is a good example of this behaviour. On Thursday, October 24, 2002, at 08:17 PM, Michael Cashwell wrote: During this section of code I have the network funnel. If I understand correctly, that protects me from any other running thread (even on MP systems). Again, can someone confirm? Yes, you're protected. My real worry is about my own thread's behavior. I understand that kernel threads can block and if they do then I loose and regain the funnel. But since I can avoid making calls that block I can handle that. But what about preemption? If my thread runs out of its time quantum might it get preempted (and again loose and regain the funnel)? My understanding is that the time quantum runout is deferred until the kernel processing is finished. I'm not certain of that, though, so hopefully someone else on the list can confirm. But sanity dictates that this must be so. Otherwise you'd always be running the risk of leaving kernel structures in inconsistent states. Think about what would happen if time ran out while tcp_output was part way through processing an mbuf to end. Ouch. And lastly, whatever the solution to that is ("kernel threads can't be preempted" or "use splnet() / splx()", or something else), what about paths into my NKE that are really user threads that have called into the kernel (through the network stack)? (Can that happen or is everything in the kernel run on a kernel thread with the "call" handled via a kernel thread blocking on a queue?) If it can happen, do I need to consider such threads as different from native kernel threads as far as preemption in my NKE goes? Output and input processing are handled differently. It helps to think of output as a synchronous process, done in response to a syscall from user-land. It operates in kernel mode, but in a way it's something like an extended function call. Input is handled on an interrupt-driven basis, and not in the context of the target user or process. Part of the processing is done directly in response to the hardware interrupt and some is queued, as I understand, but it's not in the user thread or context etc. Regards.....Peter _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.