site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 11, 2006, at 3:36 AM, Michael Smith wrote: On Oct 10, 2006, at 10:19 PM, Arvind Dalvi wrote: -Mike _______________________________________________ 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... how about developing I/O Media Filter? "An I/O Media Object acts as a channel for all I/O that goes to the storage underlying it" http://lists.apple.com/archives/Darwin-development/2002/May/ msg00382.html Again, this puts you on the hot path for potentially thousands of operations a second, to update a UI at a fraction of that rate. Unless you are trying to gather statistics that aren't otherwise available, not a good idea. Granted, if the info were otherwise available then adding anything to the hot-path would be wasteful. But if the only thing such an IOMedia filter did was accumulate the amount of data read and written as the commands flew by and then (at a much slower pace) provided those sums when requested by a userland UI component it shouldn't be overly expensive. The actual additional hot-path code is a couple of atomic adds. So as long as the layering infrastructure itself is not heavyweight then it should be acceptable. If adding just a NOP-layer is too expensive then there's a more fundamental problem. Also, to be fair, the rate that IO commands go by has nothing to do with the update rate in the UI. The hot-path would not trigger or invoke UI updates. It would only accumulate their sizes. This email sent to site_archiver@lists.apple.com