<strong>I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.</strong><hr></blockquote>You opened the wrong thing.
Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.
As for the last, the whole Finder does not grind to a halt when working on remote directories. Just the single Finder window that is accessing the remote directory--iDisk here. All other Finder windows work fine as long as you do not try to also access the (same) iDisk in them as well.</strong><hr></blockquote>
Yes, now wouldn't that be a total pain? This is how the Finder should work when working with regular directories also. Say it's run into a folder containing a lot of files/inodes/whatever (have you noticed I'm not that into techspeak? that it has to read, then just show the spinning arrows in the top right corner of the statusbar while loading and let you continue working with other Finder-windows. This should be possible, since other applications can access the file system just fine while the Finder's locked in the Spinning Harddisk-cursor Of Perpetual Annyoance. While the Finder's busy spending a minute rolling its thumbs trying to read my 300+ file & folder directory, I can easily switch to BBEdit and use the file dialogue to browse, open and save files.
So why shouldn't the Finder be able to do this? This makes me think there's something more fundamentally wrong with the way the Finder's coded rather than blaming it on the kernel.
[ 03-28-2002: Message edited by: Whyatt Thrash ]</p>
- Even if you're right with your funnel theory, connecting to an iDisk should not block local disk operations or even general event handling in the Finder since I don't think that reading a local directory or selecting a folder does actually perform network system calls, do you?
- I also don't think that connecting to an iDisk is only one BLOCKING sys call, and iDisk navigation even less. Therefore you should be able to connect and navigate several iDisks in parallel without having to wait for each operation to fully complete. (Webdav uses tcp, which means that all connect/send/receive operations can be done asynchronously.)
</strong><hr></blockquote>
I'm guessing that the reason for iDisk access blocking the Finder is just that it's a half-arsed implementation, as it has been since Mac OS 9. It seems that they simply plugged in some remote directory functionality under the normal calls for folder navigation, so the Finder does all those things like reloading a folder's contents when the window is activated, checking if the folder still exists when you try to drop a file on it, and getting a file's information and preview when you select it, just as if it was a local disk. Those calls are probably implemented as simple function calls, which return very quickly for local file listings, but when they have to get all that information through a modem, the spinning cursor is what you get.
So (if any of my speculation is actually true), they should do two things:
- Rethink the way they wait for those meant-to-be-quick functions to finish, like through callbacks or more threads.
- Make the Finder more aware of remote disks, so it only accesses them when it really has to and uses more or smarter caching.
Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.</strong><hr></blockquote>
Your right. Duh.. I was starting to think I removed that line (fake finder) from the finder.app all together for some reason.
99.9% of the developers won't put the required effort into a carbon app to make them on par with cocoa apps. Therefore carbon sucks.
</strong><hr></blockquote>
This fails any sort of test of elemental logic. I was enjoying the posts until you decided that carbon sucks because developers are lazy, (which appears to be a constant point with you.)
Carbon might suck for other reasons, but it's hardly Carbon's fault that the developer community is a burr in your ass.
AirSluf: (what does that MEAN, anyway?) Won't putting more 'funnels' into the kernal make the kernal more open to crashes? The less you have accessing the kernal the more stable the kernal theoretically is. Right?
<strong>AirSluf: (what does that MEAN, anyway?) Won't putting more 'funnels' into the kernal make the kernal more open to crashes? The less you have accessing the kernal the more stable the kernal theoretically is. Right?</strong><hr></blockquote>
Kernel. Kernel. Kernel kernel kernel. Now you try.
Exactly! A level of abstraction (as provided by a virtual file system) is very useful, though. Instead of having to rewrite code for all kinds of file systems, a programmer can just use generic calls for all file systems (remote nfs, local ufs etc.). You don't even have to know what file system you are accessing. However, these calls should of course not block or you need at least to be aware that they do and that there is a huge difference between blocking local and blocking network access (which can take an indefinite time to complete). Unfortunately, the Finder developers don't seem to understand that.
AirSluf:
As I've already stated, a directory listing is not just one sys call. This means that you are in kernel mode only for very short time periods. Now, how do you want to hold the kernel funnel while being in user space? You can't. Hence, it's perfectly possible to implement file browsers who work in parallel even on the very same directory.
I also don't see how this should lead to an inconsistent file system. System calls which change file or inode information are "atomic" in the sense that inodes are being locked during those operations (on a per inode basis). Please show me an example of how you get an inconsistent file system (I am talking about the file system itself, not the Finder representation thereof).
Now, please perform these two experiments (I haven't updated to 10.1.3 yet, so these problems may already be resolved):
A nice dialog appears. Now, while the finder is trying to connect, go to your home directory and create a new folder. Oops... that's what I call a carefully designed threading concept!!!
Cancel the connection. Open two Finder windows and move them next to each other. Now connect to an actually existing iDisk. While the Finder is connecting, keep switching between the two Finder windows. At some point, the spinning CD will appear, you can't switch between the two windows during that time although these windows have absolutely NOTHING to do with BSD network services.
Accessing vnodes could actually be implemented in two ways (As I've said, I don't know much about the implementation in darwin):
- blocking: you make a sys call and will be put to sleep until the node can be loaded and becomes available. In this case you would lose the funnel and all other threads could compete for it, too.
-non-blocking: A call would immediately return and you would have to poll or something.
Either way, you wouldn't hold the funnel long enough for other threads not being able to do event checking, which is the reason for the appearance of the spinning disk cursor . BTW: This is also why always the whole app is blocked (not just one window as you've stated). The simple explanation for this behaviour (network as well as dir listing) is that the Finder is poorly programmed.
I agree that there are several ways to deal with the Finder problems and I also want those issues to be resolved sooner than later. However, the only point I am intending to make here is that the kernel funnels are not responsible for most of the Finder's sluggishness/unresponsive CD spinning, especially not when reading a directory. It's obvious that a user app like the Finder has to deal with inconsistency and probably has to develop its own locking/notifying/whatever mechanisms, but that's the Finder's own problem and not a kernel issue (and it's not done well at the moment).
[quote]
1. Did you really mean to cause that panic!
<hr></blockquote>
No, I only wanted to show you that modal dialog. As you've said, this IS a design issue. Who would ever use a modal dialog here? This is just to demonstrate the Finder developers' lack of understanding of thread design/organizing, which I still make responsible for most of the Finder's blocking issues.
[quote]
1/2 sec, just enough to notice + a smidge. Not enough to get me upset though.
<hr></blockquote>
Actual times don't matter, design matters. For you it's still fast enough, for others it's not. Besides, all sort of things may happen and this 1/2 second becomes a minute. See, as long as you can't guarantee upper limits for delays caused by system calls you can't control, blocking JUST MUST NOT happen, never! You can't just say, well, reading a directory usually takes less than half a second, so let's not set up a seperate thread for event checking during that time. Someone has a few thousand files in a directory on a slow device or uses a remote device with a ping of several seconds and the delay becomes unbearable.
You write, on a DP, only the target window doesn't respond but the others work fine (now that's interesting, have to check this on a DP)... well, this is exactly (more or less, you should also be able to move that window around or close it, for example) how it should work on SP machines, too. Unfortunately, it doesn't.
I can't speculate on what the problems with the Finder are on a system-level basis. What I can tell you and have been telling all along is that your theory on the implementation of funnels are damn wrong, and that's what you've been adamantly suggesting throughout this entire thread.
All I'm suggesting are two points. First you should of course try to determine the source of the problem and fix that. But funnels are not the issue, and adding more wouldn't resolve the issue, because while the Finder remains locked (maybe because was programmed to think that there should be a funnel lock and prevent further input) ANY OTHER app can STILL access the file system through BSD system calls just fine. Read directories, open/save files whatever. The Finder is the only app that remains locked. So the "poor implementation" of funnels is NOT IT.
Of course Finder programmers should try to find why it's so slow and solve that problem, but something I find much more disturbing than the fact that things are slow (which the whole OS is more or less) is the fact that the Finder's programmed in such a manner as to prevent user input while a task is being performed, no matter what the task is. Reading a file directory in one window shouldn't prevent other Finder windows from reading/copying files, whatever. Of course that's a design decision, but not one that coincides with the marketing of OS X as a multitasking OS.
Now before you start blurting out techspeak, try to understand the problem on a user-level basis. Because when it comes down to it, that's all that matters. 123 has understood the problem at hand, and I applaud his ability to explain the matter more closely in a technical way that I cannot. but I can still see the effects it has and draw my own conclusions from it. Seems like you're too busy staring at the kernel and the "beautiful technical solution" to look for real, practical solutions.
[ 04-04-2002: Message edited by: Whyatt Thrash ]</p>
First of all, it's TaNenbaum, I truly hope, you haven't read a book about christmas or something... ;-)
While reading books and believing in yourself is certainly great, the ability to actively use your knowledge and draw useful conclusions is much more important. What we are discussing here is not something you can just take from the books. We are talking about strange Finder behaviour and how it can be explained and how (and why, and here the books will help you) it cannot. I actually hate to repeat myself, I think everything has been said and everybody should understand that by no means kernel funnels can be responsible for the complete blocking if you read a directory (on a SP machine).
About symptom fixes:
If a->b doesn't hold, it's useless to fix a(the "root cause"), you'd still have the b problem.
Now, if you really can't stop thinking about funnels, come up with some serious and detailed thread schedules that show when and why which funnel is held by which thread and why other threads are blocked and can't read another directory for example. It should be fairly easy to do, as long as you believe enough in your theory. Until then, please stop talking about the "root cause" and "symptom fixes".
Comments
<strong>I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.</strong><hr></blockquote>You opened the wrong thing.
Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.
<strong>
As for the last, the whole Finder does not grind to a halt when working on remote directories. Just the single Finder window that is accessing the remote directory--iDisk here. All other Finder windows work fine as long as you do not try to also access the (same) iDisk in them as well.</strong><hr></blockquote>
Yes, now wouldn't that be a total pain? This is how the Finder should work when working with regular directories also. Say it's run into a folder containing a lot of files/inodes/whatever (have you noticed I'm not that into techspeak?
So why shouldn't the Finder be able to do this? This makes me think there's something more fundamentally wrong with the way the Finder's coded rather than blaming it on the kernel.
[ 03-28-2002: Message edited by: Whyatt Thrash ]</p>
<strong>
- Even if you're right with your funnel theory, connecting to an iDisk should not block local disk operations or even general event handling in the Finder since I don't think that reading a local directory or selecting a folder does actually perform network system calls, do you?
- I also don't think that connecting to an iDisk is only one BLOCKING sys call, and iDisk navigation even less. Therefore you should be able to connect and navigate several iDisks in parallel without having to wait for each operation to fully complete. (Webdav uses tcp, which means that all connect/send/receive operations can be done asynchronously.)
</strong><hr></blockquote>
I'm guessing that the reason for iDisk access blocking the Finder is just that it's a half-arsed implementation, as it has been since Mac OS 9. It seems that they simply plugged in some remote directory functionality under the normal calls for folder navigation, so the Finder does all those things like reloading a folder's contents when the window is activated, checking if the folder still exists when you try to drop a file on it, and getting a file's information and preview when you select it, just as if it was a local disk. Those calls are probably implemented as simple function calls, which return very quickly for local file listings, but when they have to get all that information through a modem, the spinning cursor is what you get.
So (if any of my speculation is actually true), they should do two things:
- Rethink the way they wait for those meant-to-be-quick functions to finish, like through callbacks or more threads.
- Make the Finder more aware of remote disks, so it only accesses them when it really has to and uses more or smarter caching.
<strong>You opened the wrong thing.
Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.</strong><hr></blockquote>
Your right. Duh.. I was starting to think I removed that line (fake finder) from the finder.app all together for some reason.
<strong>
99.9% of the developers won't put the required effort into a carbon app to make them on par with cocoa apps. Therefore carbon sucks.
</strong><hr></blockquote>
This fails any sort of test of elemental logic. I was enjoying the posts until you decided that carbon sucks because developers are lazy, (which appears to be a constant point with you.)
Carbon might suck for other reasons, but it's hardly Carbon's fault that the developer community is a burr in your ass.
<strong>AirSluf: (what does that MEAN, anyway?) Won't putting more 'funnels' into the kernal make the kernal more open to crashes? The less you have accessing the kernal the more stable the kernal theoretically is. Right?</strong><hr></blockquote>
Kernel. Kernel. Kernel kernel kernel. Now you try.
-DisgruntledQS733Owner
Exactly! A level of abstraction (as provided by a virtual file system) is very useful, though. Instead of having to rewrite code for all kinds of file systems, a programmer can just use generic calls for all file systems (remote nfs, local ufs etc.). You don't even have to know what file system you are accessing. However, these calls should of course not block or you need at least to be aware that they do and that there is a huge difference between blocking local and blocking network access (which can take an indefinite time to complete). Unfortunately, the Finder developers don't seem to understand that.
AirSluf:
As I've already stated, a directory listing is not just one sys call. This means that you are in kernel mode only for very short time periods. Now, how do you want to hold the kernel funnel while being in user space? You can't. Hence, it's perfectly possible to implement file browsers who work in parallel even on the very same directory.
I also don't see how this should lead to an inconsistent file system. System calls which change file or inode information are "atomic" in the sense that inodes are being locked during those operations (on a per inode basis). Please show me an example of how you get an inconsistent file system (I am talking about the file system itself, not the Finder representation thereof).
Now, please perform these two experiments (I haven't updated to 10.1.3 yet, so these problems may already be resolved):
Chose "connect to server" and try to connect to "http://www.apple.com".
A nice dialog appears. Now, while the finder is trying to connect, go to your home directory and create a new folder. Oops... that's what I call a carefully designed threading concept!!!
Cancel the connection. Open two Finder windows and move them next to each other. Now connect to an actually existing iDisk. While the Finder is connecting, keep switching between the two Finder windows. At some point, the spinning CD will appear, you can't switch between the two windows during that time although these windows have absolutely NOTHING to do with BSD network services.
Accessing vnodes could actually be implemented in two ways (As I've said, I don't know much about the implementation in darwin):
- blocking: you make a sys call and will be put to sleep until the node can be loaded and becomes available. In this case you would lose the funnel and all other threads could compete for it, too.
-non-blocking: A call would immediately return and you would have to poll or something.
Either way, you wouldn't hold the funnel long enough for other threads not being able to do event checking, which is the reason for the appearance of the spinning disk cursor . BTW: This is also why always the whole app is blocked (not just one window as you've stated). The simple explanation for this behaviour (network as well as dir listing) is that the Finder is poorly programmed.
123
I agree that there are several ways to deal with the Finder problems and I also want those issues to be resolved sooner than later. However, the only point I am intending to make here is that the kernel funnels are not responsible for most of the Finder's sluggishness/unresponsive CD spinning, especially not when reading a directory. It's obvious that a user app like the Finder has to deal with inconsistency and probably has to develop its own locking/notifying/whatever mechanisms, but that's the Finder's own problem and not a kernel issue (and it's not done well at the moment).
[quote]
1. Did you really mean to cause that panic!
<hr></blockquote>
No, I only wanted to show you that modal dialog. As you've said, this IS a design issue. Who would ever use a modal dialog here? This is just to demonstrate the Finder developers' lack of understanding of thread design/organizing, which I still make responsible for most of the Finder's blocking issues.
[quote]
1/2 sec, just enough to notice + a smidge. Not enough to get me upset though.
<hr></blockquote>
Actual times don't matter, design matters. For you it's still fast enough, for others it's not. Besides, all sort of things may happen and this 1/2 second becomes a minute. See, as long as you can't guarantee upper limits for delays caused by system calls you can't control, blocking JUST MUST NOT happen, never! You can't just say, well, reading a directory usually takes less than half a second, so let's not set up a seperate thread for event checking during that time. Someone has a few thousand files in a directory on a slow device or uses a remote device with a ping of several seconds and the delay becomes unbearable.
You write, on a DP, only the target window doesn't respond but the others work fine (now that's interesting, have to check this on a DP)... well, this is exactly (more or less, you should also be able to move that window around or close it, for example) how it should work on SP machines, too. Unfortunately, it doesn't.
123
[ 04-03-2002: Message edited by: Whyatt Thrash ]</p>
All I'm suggesting are two points. First you should of course try to determine the source of the problem and fix that. But funnels are not the issue, and adding more wouldn't resolve the issue, because while the Finder remains locked (maybe because was programmed to think that there should be a funnel lock and prevent further input) ANY OTHER app can STILL access the file system through BSD system calls just fine. Read directories, open/save files whatever. The Finder is the only app that remains locked. So the "poor implementation" of funnels is NOT IT.
Of course Finder programmers should try to find why it's so slow and solve that problem, but something I find much more disturbing than the fact that things are slow (which the whole OS is more or less) is the fact that the Finder's programmed in such a manner as to prevent user input while a task is being performed, no matter what the task is. Reading a file directory in one window shouldn't prevent other Finder windows from reading/copying files, whatever. Of course that's a design decision, but not one that coincides with the marketing of OS X as a multitasking OS.
Now before you start blurting out techspeak, try to understand the problem on a user-level basis. Because when it comes down to it, that's all that matters. 123 has understood the problem at hand, and I applaud his ability to explain the matter more closely in a technical way that I cannot. but I can still see the effects it has and draw my own conclusions from it. Seems like you're too busy staring at the kernel and the "beautiful technical solution" to look for real, practical solutions.
[ 04-04-2002: Message edited by: Whyatt Thrash ]</p>
While reading books and believing in yourself is certainly great, the ability to actively use your knowledge and draw useful conclusions is much more important. What we are discussing here is not something you can just take from the books. We are talking about strange Finder behaviour and how it can be explained and how (and why, and here the books will help you) it cannot. I actually hate to repeat myself, I think everything has been said and everybody should understand that by no means kernel funnels can be responsible for the complete blocking if you read a directory (on a SP machine).
About symptom fixes:
If a->b doesn't hold, it's useless to fix a(the "root cause"), you'd still have the b problem.
Now, if you really can't stop thinking about funnels, come up with some serious and detailed thread schedules that show when and why which funnel is held by which thread and why other threads are blocked and can't read another directory for example. It should be fairly easy to do, as long as you believe enough in your theory. Until then, please stop talking about the "root cause" and "symptom fixes".
123