Users rides glitch?

StangFlyer · 09-15-2000, 05:58 AM

OK, now I understand a little bit better what you are saying. From your original message I thought what you meant was to have a central (i.e. one) que file. Of course, if that were the case each instance of the CGI would be reading and writing to it, you have to have a lock file for that, and you'd still have to use the locking file to protect the main files. Which, of course, made no sense because you're just doing what I already am now, and more. Plus you're still working on the main data files. In essence, it would just make it MORE complex and make you work with more files. However, what you are actually suggesting is that you make multiple que files. One for each update that needs to occur to the main data file. When an instance of the CGI is launched, it would read in (and delete) each que file in order of their time stamps (basically) and update whatever data each que file directed in the main data file. You would still have to use the lock file, however, because you'd still have to make sure that more than one instance is not trying to do this procedure on the main data file at the same time. Right?

So, you wouldn't really totally eliminate the locking file system, but it would significantly reduce waiting processes because a process would only have to wait if que files existed. This wouldn't be nearly as often since not every instance needs to write information, the majority of the time it just needs to read it. And, you can have multiple instances (or programs) reading a file at the same time, you just can't have them writing at the same time (or reading and writing at the same time).

I still think the only way to totally eliminate the locking file and need for any instances to wait would be through a daemon working as I described. Unless I'm still not seeing something in your plan.

Now, in other notes, if the CGI needs to wait it uses a "sleep" command in Perl. What's giving me a chuckle is that you keep sighting Window's stuff. Unlike Windows, where as soon as you just boot to the desktop it's running dozens of darn DLL's and service processes in the background, Unix (Linux in this case) is nothing more than one central "kernel". The OS Kernal is actually very small and uses little resources. Upon boot up, the only thing running is the main Kernal and whatever daemons (services) you define and actually need. This for example on our server for MW's would be a daemon for Apache, FTP, sendmail, MySql, among a few others. Most other functions are completely autonomous modules that do everything. Such as renaming a file, moving a file, editing a file, changing file permission, X-Windows, whatever. When you type the command to move a file called "readme.txt", for example, to another directory from its currently location, which is say "mv /home/readme.txt /etc/readme.txt", it invokes an external program called "mv" which resides in the "/bin" directory. That module loads, does what you directed, and exits. In other words, all the functions of the Unix OS only run as needed and thus Unix has virtually no overhead. And, because you don't have all that crap running all the time at once, the thing is EXTREMELY stable. And this is why Linux, verses Windows on the same box, is way faster.

Yeah, it's not the thing for a regular home user's desktop (yet), but it's by far the most inexpensive and ideal server solution. I'm particularly happy that Allaire finally came out with Cold Fusion for Linux now...

As for these issues still occurring with a Cold Fusion and SQL Server solution, yes they are somewhat still there, but at that point its irrelevant to you because you have a heavy hitting database engine that handles it for you.

------------------
Dan McClain, Editor
The Mustang Works Magazine
1991 Mustang GT - NOVI Supercharged 377 Stroker
1999 Ford Lightning SVT - Supercharged 5.4L Triton

[This message has been edited by Dan McClain (edited 09-15-2000).]

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
User's Rides... Think about it....	Hammer	Modular Madness	2	07-23-2002 06:20 PM
Attn: Dan. "Users Rides" section only shows 2 users.	Fox Body	Blue Oval Lounge	2	02-11-2001 01:11 AM

09-15-2000, 05:58 AM	#16
StangFlyer Founder Join Date: Jun 1995 Location: Michigan Posts: 19,326	OK, now I understand a little bit better what you are saying. From your original message I thought what you meant was to have a central (i.e. one) que file. Of course, if that were the case each instance of the CGI would be reading and writing to it, you have to have a lock file for that, and you'd still have to use the locking file to protect the main files. Which, of course, made no sense because you're just doing what I already am now, and more. Plus you're still working on the main data files. In essence, it would just make it MORE complex and make you work with more files. However, what you are actually suggesting is that you make multiple que files. One for each update that needs to occur to the main data file. When an instance of the CGI is launched, it would read in (and delete) each que file in order of their time stamps (basically) and update whatever data each que file directed in the main data file. You would still have to use the lock file, however, because you'd still have to make sure that more than one instance is not trying to do this procedure on the main data file at the same time. Right? So, you wouldn't really totally eliminate the locking file system, but it would significantly reduce waiting processes because a process would only have to wait if que files existed. This wouldn't be nearly as often since not every instance needs to write information, the majority of the time it just needs to read it. And, you can have multiple instances (or programs) reading a file at the same time, you just can't have them writing at the same time (or reading and writing at the same time). I still think the only way to totally eliminate the locking file and need for any instances to wait would be through a daemon working as I described. Unless I'm still not seeing something in your plan. Now, in other notes, if the CGI needs to wait it uses a "sleep" command in Perl. What's giving me a chuckle is that you keep sighting Window's stuff. Unlike Windows, where as soon as you just boot to the desktop it's running dozens of darn DLL's and service processes in the background, Unix (Linux in this case) is nothing more than one central "kernel". The OS Kernal is actually very small and uses little resources. Upon boot up, the only thing running is the main Kernal and whatever daemons (services) you define and actually need. This for example on our server for MW's would be a daemon for Apache, FTP, sendmail, MySql, among a few others. Most other functions are completely autonomous modules that do everything. Such as renaming a file, moving a file, editing a file, changing file permission, X-Windows, whatever. When you type the command to move a file called "readme.txt", for example, to another directory from its currently location, which is say "mv /home/readme.txt /etc/readme.txt", it invokes an external program called "mv" which resides in the "/bin" directory. That module loads, does what you directed, and exits. In other words, all the functions of the Unix OS only run as needed and thus Unix has virtually no overhead. And, because you don't have all that crap running all the time at once, the thing is EXTREMELY stable. And this is why Linux, verses Windows on the same box, is way faster. Yeah, it's not the thing for a regular home user's desktop (yet), but it's by far the most inexpensive and ideal server solution. I'm particularly happy that Allaire finally came out with Cold Fusion for Linux now... As for these issues still occurring with a Cold Fusion and SQL Server solution, yes they are somewhat still there, but at that point its irrelevant to you because you have a heavy hitting database engine that handles it for you. ------------------ Dan McClain, Editor The Mustang Works Magazine 1991 Mustang GT - NOVI Supercharged 377 Stroker 1999 Ford Lightning SVT - Supercharged 5.4L Triton [This message has been edited by Dan McClain (edited 09-15-2000).]