site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, You're right, it is. You should, instead, either: What problem? Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ 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 7 Sep 2007, at 22:00, Michael Smith wrote: On Sep 7, 2007, at 12:21 PM, Anton Altaparmakov wrote: 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. Surely the overhead of starting a thread would be far too high to make such a thing worth doing? [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...] So fix the problem; don't cite it as an excuse for writing bad code... Sorry but you cannot be talking seriously. Lets just say I had nothing better to do and went and rewrote the OSX kernel you cannot seriously be suggesting that I would not be totally wasting my time as no-one would accept my new code as it would break backwards compatibility/API/ABI/everything in existence. You can do that on Linux (and such work is in fact ongoing to better support cluster file systems!) but in the world of companies like Apple that would never happen. 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... This discussion is becoming pointless, sorry. It has nothing to do with my FS design. 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()... So fix the problem; don't cite it as an excuse for writing bad code... Care to rewrite the VFS/VM <-> FS kext interface and fix up all file systems? No? Me, neither... I'd love to. Yes but aren't doing it as you know your changes would not be accepted. So stop making impossible suggestions please! They are not productive and just waste everyone's time (well ok, my time reading and replying anyway)... This email sent to site_archiver@lists.apple.com