site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Sep 5, 2007, at 12:18 PM, Terry Lambert wrote: is: -- Shaun Wexler MacFOH http://www.macfoh.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com So as someone suggested, I'm now using IOSleep instead, which seems to do exactly what I want to do (why would I want to do IODelay? Where is the advantage of wasting plenty of CPU time for a couple of ms - a spin lock is maybe meaningful if you sleep for a couple of ns or us, because there the sleep/wake-up would take longer than the actual time to sleep, but if you sleep more than one ms, I guess it's fine to real put the thread to sleep). The general reason for using IODelay(), according to the Kernel Programming Guide at: <http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/KernelProgramming.pdf> IODelay, provided by the I/O Kit, abstracts a timed spin. If you are delaying for a short period of time, and if you need to be guaranteed that your wait will not be stopped prematurely by delivery of asynchronous events, this is probably the best choice. If you need to delay for several seconds, however, this is a bad choice, because the CPU that executes the wait will spin until the time has elapsed, unable to handle any other processing. So personally, I'd use it if I were a hardware manufacturer who had made a cost trade-off to reduce the COGS on my hardware by skimping on FIFO space, and needed a guaranteed service latency so that it didn't drop data. And I'd hope that if I did this, the hardware was intended to have only intermittent use, so that it didn't become a performance problem for everything else on the machine. So, for example, a QIC-40/QIC-80 floppy tape drive attached to a floppy controller with a 16 byte FIFO would probably qualify (but there are other cleverer tricks you could do instead with that particular hardware to keep it streaming; the BSDI driver was a thing of beauty). IODelay could have been implemented as an inline spin loop which reads the timebase registers, but it was not, thus the documentation is somewhat misleading. There is no underlying difference between IOSleep and IODelay functions, except for the granularity of their argument (mS vs µS). They both call down to clock_delay_until(), which sleeps the calling thread if preemption is enabled or the sleep time is longer than the duration of (8x) context switches, etc. Use IODelay if you need to sleep/spin for times and/or granularities less than 1 ms, else use IOSleep. smime.p7s