> That is also the problem with just creating a file that is used to provide the html page containing the "refresh" and then just replacing it with the > real file containing all the data. That is if the "refresh" > occurs in the middle of writing the file and the file is read before the write completes.
That is why I suggested writing to another file name and when the write is complete, delete the status file and rename the output file to the status file name. If you lock the file and overwrite it, as was previously suggested, and the file is very large, the time required to write the file and unlock it leaves a large window of time during which the refresh of the status page will cause the server to return an error because the file is in use. A delete and rename sequence should take a very small amount of time, and will take the same amount of time regardless of how large the final output file is. Glenn Lawler www.incodesystems.com -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Doug Hale Sent: Wednesday, July 07, 2010 11:43 AM To: [email protected] Subject: [delphi-en] Was CGI now race condition. The whole thing is not a race condition. The effect of just missing an event and having to wait for another cycle is just the way synchronization works. If it is true that a newly created file is visible after the first write and before it is closed, then that creates a race condition. The "race" is to finish writing to the file before reading the file finishes - due to the file being "discovered" before it all writes complete. That is also the problem with just creating a file that is used to provide the html page containing the "refresh" and then just replacing it with the real file containing all the data. That is if the "refresh" occurs in the middle of writing the file and the file is read before the write completes. The way to solve the "race" is to not allow the file to be read until all writes are completed. One way is through file locking. But there are other ways. One way is to know how much time is required from the time the file can be first discovered until the all the writes complete. Then delay the first read after the file discovery by that much time. This is generally the way race conditions are solved in hardware because the delays are quite predictable and small. But not all that great for software because the delays are not so predictable. Another is to use a different "trigger" that the creation of the file. If the Session State is used, then it must be semaphored or locked. A different file could be used that is only created but not read or written. But the cost of creating the different file (and deleting it later) needs to be compared to the cost of file locking (and waiting to acquired the lock if it is held by another) And I'm sure there are many other ways... Doug
