OS APIs without error codes

[rdos]

meaning you fail to understand, and that word has already been mentioned: "flexibility".

Flexibility? I already wrote in another post that few, if any, RDOS API function has more than one possible error cause that doesn't include faulty programs. What kind of flexibility is one error code returns (+ invalid handle)?

Part of the design idea is to keep syscalls simple so they don't need lots of error-codes.

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.

And the generalization put forward to this answer was not correct: Just because nobody at this forum will ever program RDOS API, doesn't mean the idea can be discarded because nobody uses RDOS. The topic is not about RDOS. It is about an idea, and it is silly to discard an idea because "you don't want to program a particular implementation of the idea".

I'm fine with you not wanting to program any particular implementation of this idea, and even that you find it stupid and silly, but that doesn't make the idea unintersting to others that might want to use it in their own implementation.

And, more important: don't imply that solutions that work for RDOS will always work and are far superior - because you are just wrong.

Most design ideas are not inferior/superior. If you think of design ideas in this way you need to think again. If there only existed one good way of doing things, we would not have any variation in design ideas. Instead, different designs have positive and negative aspects, and these frequently are related to what they would be used for.

And yes, you are implying that they are superior, you do it in every thread lately.

OK, then provide a reference for your claim. I can garantee that I have not written anywhere that any design idea in RDOS is superior.

EDIT: And don't use the title of the thread originally named "Best processor for 32-bit OS", as I had no saying in moderators changing the title without asking the thread creator for permission for doing that.

[Owen]

The main issue I have, is that, without error codes, you can't have synchronous error reporting.

For example, for a create file call, there are the following possible errors (plus any extra system-specific ones):

• Kernel/VFS server memory exhausted/resource limit reached
• File already exists
• Parent directory does not exist
• Access denied
• Symbolic link loop
• Name too long
• Out of disk space
• Device read-only
• Component of path-prefix not a directory

Precisely none of these can be accurately diagnosed by calling separate functions, because, on a mult-threaded system, another process can change the the file system in between the time you make your inquiry call and the time you actually call create file. You can't accurately diagnose things afterwards, either, because again, another process may have changed conditions.

[Solar]

Don't imply that solutions that work for RDOS will always work and are far superior - because you are just wrong. And yes, you are implying that they are superior, you do it in every thread lately.

OK, then provide a reference for your claim. I can garantee that I have not written anywhere that any design idea in RDOS is superior.

To quote from this post, where you made exactly that claim for exactly this thread's subject:

[...] C cannot handle using the CY flag to signal return status. This is clearly superior to using a whole return-register for status [...].

So much for your "guarantee".

The next such blatant lie will make me request a forum ban for you, because you are being disruptive.

[Brendan]

Hi,

I already wrote in another post that few, if any, RDOS API function has more than one possible error cause that doesn't include faulty programs.

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?

It seems severely broken to me, unless the OS is single-tasking and the application can know that no other tasks are going to change things between calls. Even if the OS is single-tasking, it's still completely idiotic - up to 4 kernel calls (complete with "CPL3 -> CPL0 -> CPL3" switches and probably a full infestation of segment register loads) when only one would be needed for a sane API.

The only good reason to not return error codes is if you're using exceptions (e.g. "try { .. } catch() { ... }") instead, but to be honest I really don't like exceptions much either (they look messy, and have all the problems of "goto" but worse because the target might not be in the same piece of code).


Cheers,

Brendan

[rdos]

Don't imply that solutions that work for RDOS will always work and are far superior - because you are just wrong. And yes, you are implying that they are superior, you do it in every thread lately.

OK, then provide a reference for your claim. I can garantee that I have not written anywhere that any design idea in RDOS is superior.

To quote from this post, where you made exactly that claim for exactly this thread's subject:

[...] C cannot handle using the CY flag to signal return status. This is clearly superior to using a whole return-register for status [...].

So much for your "guarantee".

The next such blatant lie will make me request a forum ban for you, because you are being disruptive.

1. It is not a design issue
2. C cannot return CY

So, you are the one providing blatant lies..

[rdos]

The main issue I have, is that, without error codes, you can't have synchronous error reporting.

For example, for a create file call, there are the following possible errors (plus any extra system-specific ones):
Kernel/VFS server memory exhausted/resource limit reached

Unresolvable

File already exists

Possible to check

Parent directory does not exist

Possible to check

Access denied

Not supported

Symbolic link loop

Not supported

Name too long

Uhhm, A mixture of "programmer should know name limits in the FS", and unresolvable

Out of disk space

Possible to check

Device read-only

Not supported

Component of path-prefix not a directory

Possible to check

Precisely none of these can be accurately diagnosed by calling separate functions, because, on a mult-threaded system, another process can change the the file system in between the time you make your inquiry call and the time you actually call create file.You can't accurately diagnose things afterwards, either, because again, another process may have changed conditions.

That is bad practise, but it is resolvable in this way:

Code: Select all

   ok = FALSE;
   fatal = FALSE;
   while (!fatal && !ok)
   {
       fatal = CheckPreCondiitions(path);
       ok = CreateFile(path);
    }

[rdos]

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. Somebody basically wrote a buggy application, and you cannot resolve buggy applications with error-code processing.

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"

In case 2, your FS performance will suck since you are basically doing unbuffered IO to your physical storage device.

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.

[bluemoon]

View from application, if the io operation is fully processed and buffered it's usually treated as success.

If the buffer somehow fail to flush to actual device, it's a system failure. For example, on windows you will see an "improper eject of device" message.

[Cognition]

Wouldn't it be easier to simply use a bitmask to return multiple error conditions? It seems like it'd work under most scenarios pretty well, perhaps there are some scenarios were you would have to worry about handling more than 32 or 64 error conditions but I can't imagine there would be many. At any rate in such scenarios calling several syscalls to resolve the error would definitely be a huge performance hit as well.

[Brendan]

Hi,

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.

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)".

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.

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).

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

[bubach]

Why even care what he does or think? And disruptive? Banning? Seriously, chill out.
You can't convert everybody to your beliefs. Not that I agree -
but I simply don't care even if he was to call it superior or whatever.



Caring too much looks ridiculous after a while.

[Solar]

"On the internet" I could stand, but I tend to think of this forum as some kind of "digital /home", which - I admit - makes me care a bit too much.

[bubach]

Hahahah! So basically - from your point of view - rdos comes into your home and takes a **** on your carpet? That explains a lot.

[Cognition]

Yes, bitmasks with thousands of bits (see EMAXERRNO).

This doesn't have to be a errno replacement, it's simply a method for returning multiple error conditions from a syscall. If one was really tied to the errno interface the functionality to convert the codes could be done in userspace anyways. Or two registers could be used for return codes, one for an errno value and another with the custom api bitmask etc.

[rdos]

Yes, bitmasks with thousands of bits (see EMAXERRNO).

This doesn't have to be a errno replacement, it's simply a method for returning multiple error conditions from a syscall. If one was really tied to the errno interface the functionality to convert the codes could be done in userspace anyways. Or two registers could be used for return codes, one for an errno value and another with the custom api bitmask etc.

I like your idea. Especially since that would define the possible error returns per API, not in a huge list that is specific for each OS and version.

And for showing error reasons to users, I think returning a text string is quite adequate, and only requires a printf or similar to decode. Additionally, it would work regardless of how error-reasons are mapped to integers in the particular environment. I think Win32 has a function to convert a propietary error code into a text message.