site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com is: Regards, -- Terry _______________________________________________ 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... On Sep 5, 2007, at 1:34 AM, Markus Hanauska wrote: Okay, but in that case, could Apple please update their webpage to represent the code in a way that compiles. Many people tried to tell me, that this depends on the system version, however, I checked for 10.2, 10.3 and 10.4 and it's always the same, at least to the SDKs found in my Xcode installation. Please file a bug report with <http://bugreport.apple.com> or contact DTS about any problems you have with examples; this mailing list is an inappropriate venue for reports against Apple web sites. All complaining here does is get you frustrated people who can't do anything about your problem for you because you failed to file a bug report that they can then hang the work off of to justify their time spent as service to a customer. I tried the memcpy solution, and it worked just fine, though it's a lot of code to do a small thing, sleeping for a couple of ms. It's not "a lot of work" for the computer. The memcpy() function is highly optimized in the comm page, and unless you go out of your way to disable it, a small memcpy like this will end up being inlined as a number of load/store instructions, which is exactly what you'd get from a structure assign or assigning a 64 bit value to another that you weren't careful to align. The compiler really does know what it's doing. 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...
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). This email sent to site_archiver@lists.apple.com