Steven D'Aprano <ste...@remove.this.cybersource.com.au> wrote: > On Tue, 28 Apr 2009 14:30:02 -0500, Nick Craig-Wood wrote: > > > t123 <tom.lu...@gmail.com> wrote: > >> It's running on solaris 9. Here is some of the code. It's actually > >> at the beginning of the job. The files are ftp'd over. The first > >> thing that happens is that the files get renamed before any processing > >> of the file. And when it fails, it always fails at the first file, > >> comm.dat. What I can't understand is why the inconsistent behavior. > >> > >> try: > >> if os.path.exists(paths.xferin_dir+'/COMM.DAT'): > >> os.rename(paths.xferin_dir+'/COMM.DAT',paths.xferin_dir+'/ > > > > This code is inherently racy... What if two copies of your code started > > simultaneously? They might both run the os.path.exists but only one > > will succeed in the os.rename. > > > > You could write instead > > > > try: > > os.rename(paths.xferin_dir+'/COMM.DAT',paths.xferin_dir+'/ > COMM.DAT'+'.0') > > except OSError: > > pass > > > > Which isn't racy. > > The race condition is still there. The only difference is that in the > first case it fails noisily, with an exception, and in the second it > fails quietly and does nothing.
I'd argue that since os.rename implements the syscall rename() and that is defined to be atomic (give or take) then the above is atomic and can't possibly be racy. Wikipedia's definition :- A race condition or race hazard is a flaw in a system or process whereby the output and/or result of the process is unexpectedly and critically dependent on the sequence or timing of other events. The term originates with the idea of two signals racing each other to influence the output first. The original example was clearly racy. I guess using the wikipedia definition, the fact that I've caught the exception makes it no longer unexpected and hence no longer racy. -- Nick Craig-Wood <n...@craig-wood.com> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
