Linked by Eugenia Loli on Mon 17th Mar 2003 22:49 UTC
Graphics, User Interfaces So many operating systems and so many graphical desktop environments... This article is a comparison of the UI and usability of several Desktop Environments (DEs), that have been widely used, admired and reviled: Windows XP Luna, BeOS 6 (Dano/Zeta), Mac OS X Aqua and Unix's KDE and Gnome. Read on which one got our best score on our long term test and usage.
Permalink for comment
To read all comments associated with this story, please click here.
File locking..
by looncraz on Tue 18th Mar 2003 15:31 UTC

The most intelligent way for responsiveness is to Lock a file only on write. However, your store changes in a temporary attribute (not possible in most places, so a temporary file) until a copy task is complete of the original, then make the changes immediately afterwords. and Unlock.

Or, you can just do nothing, and let the programmers take care of it, like Linux or Zeta. That way you get this:

file->Lock();
file->Write(offset,&buffer);
file->Unlock();
file->AddAttribute(bool,"RunDeamon", true);

You had a lock of about .000002 seconds.. at most. It is very unlikely (even with a Node monitor in place) to be able to access the file at the exact same point of time the lock occurs.

Another thing that is wise, is to create a scheduler in the file system. When another app calls a file that is locked, you return a code of FILE_LOCKED, the app simply does this:

if (file->Open == FILE_LOCKED){MyNodeMonitor("unlocked", &file);}

and with your MessageReceived for your BApp or Looper:

switch (msg->what = NODE_MONITOR){
case FILE_UNLOCKED:
{
mainClass->OpenFile(mainClass->FileToOpen);
break;
}
}

That means as soon as it is no longer locked, it opens. ;-)

Of course this is just how I do it. Works for me ;-)

Okay, for all you who do not know, I just spawned two threads. A BMessageRunner thread and a BLooper thread. One which sends messages, the other which recieves ;-). I have nothing to worry about how it is done, the system does it for me, and the UI stays perfectly responsive (the work is being done by the system to alert me when the app is no longer locked).

In this case I do not display a note to the user, as this will last at the most of just a half second or so regardless of how well another app writing to the file is. The system automatically will unlock it on a schedule and suspend the other apps operations for about 2ns. Totally imperceptible, but that is what multithreading is ;-) Of course, it also depends on priority.

A priority of 10 (Normal) will result in a 2ns period of time in which the CPU is used for app #1 per schedule pass. And 15 may result in 3 or 4 (it will be revisited more often, and out of order based on priority and such from my understanding of things.

Now, of course, I just use the stuff, and write some of the other stuff, so you don't need to take my word for it. I didn't design it, or ever even see any code that does all this, but it is what happens (enough coding mistakes trying to learn how to deal with files, and you will figure it out soon enough).

--The loon (What was I talking about??)

Oh, and it should be ZBitmapButton, heh.. and a note on that (previous post I made, like #121)..

The other Bitmaps are optional, only need the first one, and leave the others as 0 (NULL), which will cause the images to be tinted or grayscaled for effects (Well, I plan on it being that way.. haven't coded it yet).