Doug Hale wrote: > On 7/6/2010 1:16 PM, Glenn B. Lawler wrote: >> Another thing to point out is that when your status page autorefreshes, it >> does not need to point to your CGI each time. It could work just as you >> describe, but I would probably use the simpler approach of having your >> initial CGI write out the status page to the same file name that will >> eventually contain the final output. This status page would contain the >> autorefresh tag. The spawned process that does the work would write its >> output to another file and when finished, it would delete the status page >> file and rename its output file to the same name as the status page. That >> way, the page the client is autorefreshing will "instantly" become the >> output page whenever the processing is complete. > > Unless the page is being written out by the shelled app when the refresh > occures, that could get messy.
Use file locking. Instead of deleting the status page and moving the result page in its place, have the the background process open the status page, lock it for writing, and copy the *contents* of the result-page file into the status-page file. Clear the "busy" state in the session data, and then unlock the file. Locking the file is important. If all processes that try to access the file also lock it (via LockFileEx), then anything that doesn't immediately lock the file will block waiting for the current lock holder to release it. >> Finally, you need to have a way to automatically clean up all these output >> files. We normally do this with another process that is running on the web >> server and automatically deletes all files older than a certain age. You >> could also do this in the process that you spawn to do the processing if you >> are using a hosting service and do not have access to the server, so that >> every time you run the process, it first deletes all output files that are >> more than 20 minutes old (or whatever criterion you choose). > > When the user logs out, the session is destroyed. There is also a > service running that watches session states. If they get too old, they > are destroyed. (Session states are updated at every request so the time > on the session state represents the time of the last state) > > The only contention problem I see now is signaling completion. If the > Shelled App uses the session state, it could be accessing it when the > refresh occurs. Not a major problem. Just lock the session file when access it. > But if I use the existence of the page file as the > completion signal, then the session state does not have to be accessed > by the Shelled App. And since, in Windows, the newly created file is not > visible until it is closed, I won't have a race condition here either. I'm certain that's not true. Files are visible when they're written. They don't have to be closed. > So, during the refresh, if the file does not exists, send another "busy" > page. If the file does exists, clear the "busy" status in the session > state, send the page and delete it. > > Do you see any contention issues or race conditions in this? The whole thing is a race condition. But since it doesn't matter who wins, it's not an issue. (If the refresh process wins, then the worst that happens is that the user has to wait for another cycle before seeing the result.) -- Rob
