OSDev.org

Posted: **Wed Apr 25, 2012 1:34 am**

Solar wrote:That is your opinion. It might even work for RDOS. In the general case, you'd want to have multitasking, and in such an environment the above design is BS.

It has nothing to do with multitasking. Well-written applications don't break because some other application deleted a file, or whatever, and don't need error code processing to handle this. If two applications uses the same files, they must somehow synchronize their access, otherwise chaos will prevail, regardless if error codes are returned or not.

Also, RDOS does provide reentrant syscalls for everything, including FS access.

Posted: **Wed Apr 25, 2012 1:45 am**

Solar is talking about general case. In general case application do not require to do any synchronization just to open file; the OS is expect to handle mutex/shared access.

Fair enough, in RDOS you can require the application to do that themselves, since you are the rule.

Posted: **Wed Apr 25, 2012 2:16 am**

rdos wrote:Well-written applications don't break because some other application deleted a file, or whatever, and don't need error code processing to handle this. If two applications uses the same files, they must somehow synchronize their access, otherwise chaos will prevail, regardless if error codes are returned or not.

In the general case an application has no idea what other application might run in parallel, and/or if other applications might access the same files. (It might even be - *gasp* - the user accessing the file, and it's hard synchronizing an application with that noteable automatically.)

The general mechanics for "synchronization" is to attempt the access, and handle potential failures. It is impossible to check all potential failures beforehand and still be certain the assertions hold true by the time you actually do the access. (Unless you disable task switching across multiple syscalls. You wouldn't want to do that.)

You've been told this by several people now, several times over, in different words, but you blithely go on ignoring it, jumping up and down and chanting "but it works in RDOS, but it works in RDOS".

We heard. We understood. We don't care (much). For the general case - and that is how this thread was started - "OS APIs without error codes" are not much of an option, for repeatedly reiterated reasons.

rdos wrote:Also, RDOS does provide reentrant syscalls for everything, including FS access.

You're such a character, dude.

Posted: **Wed Apr 25, 2012 2:32 am**

bluemoon wrote:Solar is talking about general case. In general case application do not require to do any synchronization just to open file; the OS is expect to handle mutex/shared access.

Fair enough, in RDOS you can require the application to do that themselves, since you are the rule.

I just stated that RDOS handles synchronization in the FS driver, so the application doesn't need to do that. However, if some application deliberately deletes a file that another application actively uses, the second application cannot recover from that no matter what kind of error recovery it does, unless it can recreate it, and then it can recreate it regardless if it has error codes from the FS API or not.

And if I didn't handle synchronization in the FS, how could I claim to do localized error handling? It would be impossible.

It was Solar that claimed that it would be impossible to handle multitasking without error codes from syscalls, something I claim is false. Reentrancy in the filesystem is dependent on proper synchronization, not error codes. No number of error codes could ever fix a FS that lacks synchronization.

Posted: **Wed Apr 25, 2012 2:35 am**

Solar wrote:The general mechanics for "synchronization" is to attempt the access, and handle potential failures. It is impossible to check all potential failures beforehand and still be certain the assertions hold true by the time you actually do the access. (Unless you disable task switching across multiple syscalls. You wouldn't want to do that.)

Not so. Synchronization ensures that FS contents is always consistent even if several tasks tries to modify them at the same time from different cores. You cannot ever implement that with "trial-and-error".

A special case is retrieving a directory listing of files. In the old DOS days, this used the DTA to point to specific disc sectors, which was a hopelessly silly concept that never could be extended to proper synchronization. However, in my design, a directly listing is completely independent on FS structures, and thus never can become stale. It might not be correct 1ms after the snapshot, but it was correct & consistent at the time of the snapshot.

Posted: **Wed Apr 25, 2012 3:03 am**

rdos wrote:It was Solar that claimed that it would be impossible to handle multitasking without error codes from syscalls, something I claim is false.

Don't twist my words, I warn you. You said "the OS should do it's best to perform syscalls, and when this fails, these failures are fatal and there is nothing the application can do about it provided that the application checked relevant preconditions", and I said that such a design is BS in a multitasking environment. I didn't say "impossible", I said "design akin to bovine excrement".

All in all, you seem to have problems grasping the concept of concurrency, race conditions etc.

Posted: **Wed Apr 25, 2012 3:05 am**

Hi,

rdos wrote:
Solar wrote:The general mechanics for "synchronization" is to attempt the access, and handle potential failures. It is impossible to check all potential failures beforehand and still be certain the assertions hold true by the time you actually do the access. (Unless you disable task switching across multiple syscalls. You wouldn't want to do that.)
Not so.

rdos wrote:However, in my design, a directly (directory?) listing is completely independent on FS structures, and thus never can become stale. It might not be correct 1ms after the snapshot, but it was correct & consistent at the time of the snapshot.

So you're saying that for RDOS; it is impossible to check all potential failures beforehand and still be certain the assertions hold true by the time you actually do the access? For example, you might get a directory listing to make sure a file is present, and 1ms later when you attempt to open the file it might not be present?

Cheers,

Brendan

Posted: **Wed Apr 25, 2012 3:33 am**

Brendan wrote:So you're saying that for RDOS; it is impossible to check all potential failures beforehand and still be certain the assertions hold true by the time you actually do the access? For example, you might get a directory listing to make sure a file is present, and 1ms later when you attempt to open the file it might not be present?

You cannot lock the FS because you do a directory listing.

If you want to be real extreme about a file existing, you can do as I provided code for previously (requires no error reasons)

Code: Select all


    int handle = 0;

    if (CheckFileExist(path))
         handle = OpenFile(path);

    if (!handle)
    {
         if (WantToCreateFile)
              handle = CreateFile(path);
    }

Works perfectly well.

Could even be simplified to:

Code: Select all


    int handle;

    handle = OpenFile(path);

    if (!handle)
    {
         if (WantToCreateFile)
              handle = CreateFile(path);
    }

OSDev.org

OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes

Re: OS APIs without error codes