On Monday, June 3, 2002, at 04:27 PM, Scott Taggart wrote: (The inflictor of IOWorkLoop on a poor unsuspecting world) The workloop is a nice concept. As you can see, however, there are natural questions that arise as to the "rules". All I can say is the more documentation and samples, the better ;) And one final question (for now!). I am sure that if I had enough time (which I don't), I could figure this out. And, the question itself is tricky: I don't understand *how* registering an event (interrupt, etc.) causes it to get gated (I would like the actual mechanism explained because I am curious). For example, I see one of the EN drivers registering an interrupt function as a workloop "task". When I look at the interrupt function itself, it just looks "normal" - that is it itself does nothing workloop/gate related. So, suppose we have a registered interrupt function named "InterruptFunc()". Obviously, the hardware does not generate an interrupt that directly calls this function - somehow, the gate code gets "in front" of this function, does the gate "thing" and then calls the function when it owns the gate. Would you mind explaining how the gate code gets put in "front" of a registered function (what is the "glue" that welds the source of the event (interrupt, timer, etc.) to the gate and then to the function being gated? Have you read over the following? <http://developer.apple.com/techpubs/macosx/Darwin/IOKit/IOKitFundamentals/ HandlingEvents/index.html> and <http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOWorkLoo... Classes/IOWorkLoop/index.html> and <http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOEventSo... Classes/IOEventSource/index.html> It is my understanding that workloop maintains a list of event sources. Each workloop has a single thread, the workloops thread, that an event source can signal (the trigger of event need not wait but can go on), causing the thread to wake up. This thread will check the list of event sources looking for ones that want have an event to deliver. If one is found the thread lowers the gate (or sleeps waiting for it to be raised, can happen because of IOCommandGates...) and calls the function registered for a particular event source. Basically the function related to the event source is called in the workloops thread not in that of the events source. The workloop thread sleeps when no more events need to be delivered. Now IOCommandGates work with workloop differently then event sources. They lower the workloop gate, if it is currently raised, and then calls the related command gate function in the thread of the command gates caller (humm... sorry for the poor wording). In other words it uses the gate to sync with all other command gate and event sources on the given workloop but it runs in the thread of caller. Now if the gate is currently closed I think it either triggers the workloop thread to come around when it get a chance or it sleep the calling thread waiting on the gate to raise... (need to look this up). For example in the case of an interrupt source when you init the IOInterruptEventSource you tell it what object provides the interrupts (for example a pci nub). This causes the interrupt event instance to hook itself up with the real interrupt. You also tell the event source about your driver object (usually) and what function(s) you want called when the event is fired. You then tell the workloop about this event source by using addEventSource (adds it to the list of event source), this also informs the interrupt event source about the workloop (mostly the way to signal the workloop it has an interrupt to report). Now I could be wrong but this is how I currently understand things. -Shawn p.s. The source for all of this is available via Darwin. _______________________________________________ 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.