site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Sep 7, 2007, at 12:21 PM, Anton Altaparmakov wrote: So fix the problem; don't cite it as an excuse for writing bad code... You're right, it is. You should, instead, either: So fix the problem; don't cite it as an excuse for writing bad code... I'd love to. = 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... But for example from a file system kext we don't know what priority the thread is and we don't own the thread either so we should not be messing with priorities... On the contrary. As a filesystem, if you need to perform a lengthy task, the onus is on you to ensure that you do it on a thread with an appropriate priority. If this means kicking off another thread, so be it. So I am going to spawn a kernel thread at a lower priority and block in the parent thread until that thread completes?!? That makes no sense whatsoever (at least to me)... You want the task to be pre-empted if higher priority work arrives. You don't know your current priority. Ergo, you give your work to a pre-emptable thread of known priority. [I am cheating in my example above as the lock taken by those code paths at least for my FS kext is taken shared thus there is no deadlock as both threads take the lock at the same time without deadlocking but it was a simple example illustrating how sometimes lock inversions happen because of antiquated interfaces that were designed in a uniprocessor, no preemption, one funnel for all world and not because of people's inability to write proper code...] And another example: In a critical path when a memory allocation fails, I want to yield the CPU and try again later when the system hopefully has more memory available as failing the allocation is a disaster for file system consistency at this point. At the moment I just do it in a busy loop trying again and again and again till the scheduler decides to reschedule me. That's got to be totally insane... )-: a) Fail the operation with a resource shortage error. Can't do that without leaving the FS in severe state of corruption. Keeping state and rolling back is too much effort (resources wise it would slow down things a lot) to be worth it for such an uncommon case. So fix your FS design; don't cite it as an excuse for writing bad code... b) Use one of the memory allocation primitives that knows how to wait intelligently for memory to become available. I have been told I should only be using OSMalloc()... Care to rewrite the VFS/VM <-> FS kext interface and fix up all file systems? No? Me, neither... This email sent to site_archiver@lists.apple.com