Hi,
rdos wrote:Brendan wrote:Can you describe how this "one possible error cause" is possible?
I'm currently imagining something like this:
- Application calls kernel the make sure a file is present. Kernel might return a "file not present" error.
- Application calls kernel the make sure a file has suitable permissions. Kernel might return a "bad permissions" error; but might also return a "file not present" error if some other task deleted the file at the wrong time.
- Application calls kernel to open the file. Kernel might return an "out of memory" error; but might also return a "bad permissions" error or a "file not present" error.
Now assume the "open()" failed:
- Application calls kernel to determine if the problem was a memory error. Kernel might return "there's no memory error anymore".
- Application calls kernel to determine if the problem was with file permissions. Kernel might return "there's no file permission problem anymore".
- Application calls kernel to determine if the problem was that the file doesn't exist. Kernel might return "the file currently exists".
After all of this, would the application report an error (and if so, what) or retry?
If another task deletes the file, either prior to opening it, or during the time it is open, the contents would be lost so in that scenario, both error code and boolean status returns are useless since the file doesn't exist after this procedure.
I guess you don't understand how "unlink()" works - if another task deletes the file while it's open, the file continues to exist until it's closed. This avoids the need for file locks (and the need to return a "file is currently being used" error to the task that attempts to delete the file).
Only an incompetent fool would think that both error code and boolean status returns are useless if the file was deleted and doesn't exist anymore - do you seriously want the application to think everything is fine while it continues to (attempt to) read and/or write data to something that doesn't exist?
Also note that nowhere did I say that the file is deleted. Perhaps some other task simply renamed it. Maybe it was just something like
"logrotate" doing exactly what it's designed to do.
rdos wrote:Somebody basically wrote a buggy application, and you cannot resolve buggy applications with error-code processing.
So, 2 separate application developers do an excellent job and write 2 perfect applications. Then someone installs both of these applications on the same computer and suddenly both applications are buggy? Perhaps when you say "the application is buggy" what you really mean is "the API is a steaming pile of donkey vomit, which makes it impossible to create applications that aren't buggy (unless the "multi-tasking" OS is only used with a single task/application)".
rdos wrote:Maybe you can explain to me how your, error-code API, would handle this scenario:
1. User inserts USB stick
2. A thread creates a file, which is buffered by the FS
3. User removes USB stick before the new file has been saved to USB stick
4. The call returns some status to the thread, but which?
There are two alternatives:
1. You return success because the FS has completed the buffer operation
2. You wait for all the FS data to be comitted to disc, and then return "USB-Write-Error"
Either of those alternatives is fine. The former (described by bluemoon) is what most OSs do and is much better for performance (while being worse for fault resilience). I'd probably do the latter (e.g. ensure the data is committed to disk when "close()" is called, and return an error if "close()" fails to commit buffered data to the device), but I force applications to use asynchronous file IO so that I wouldn't have a thread blocked until "close()" completes anyway.
rdos wrote:At least in my OS, file operations will succeed if the FS has buffered them, and if the physical operations on the disk fails, the application will not know about that, and those are regarded as fatal errors. That's also why mission-critical data do not use the file-API, but fixed disc sectors that have multiple copies.
Your normal file IO is so broken that any mission critical data has to avoid it like a bad disease and needs to resort to using fixed disk sectors instead? That's, um, "nice" (in a sarcastic way).
rdos wrote:Griwes wrote:And in the start you generalized. The topic wasn't "I'm thinking about implementing API without error codes in my OS that no-one will ever write programs for"
I thought this to be the case (in the recent future), but since our company has some 400 installations of two different systems, with more coming, I think the probability is rather high that somebody else will program RDOS API directly or indirecty by use of the C++ framework.
As far as I can tell, the only reason you've got some 400 installations of two different systems is that no third party developers have seen your APIs or have been able to tell much about the design of RDOS itself. If you allow third-party developers to develop applications for RDOS you will lose sales - they'll take a look at the API, assume the rest of the OS is the same quality, and (successfully) try to convince everyone around them not to touch RDOS. If you don't believe me, look at how developers here have reacted to the things you've said in this topic and other topics about RDOS. Don't forget that a lot of the people on these forums are hobbyists and/or students (like me), and aren't professionals that have earned their CS degree and worked in the industry for a while (like Solar), and none of us are betting our jobs/careers on RDOS.
Cheers,
Brendan
