On Fri, Nov 16, 2012 at 02:52:48PM -0800, Ethan Jackson wrote: > > I don't see why we're scheduling tmpfile to get deleted on exit. We're > > about to rename it away to pidfile. After we do that, someone else may > > come along and newly create a file with that name and lock it on the way > > to trying to acquire the pidfile. Deleting it will screw up that > > procedure. > > The reason is that if we die in between taking the lock, and doing the > actual rename, we leave a stale tmpfile sitting around. It's not really a > problem in the scheme of things, it just looks a bit messy. I think we can > solve the problem you site by simply calling > fatal_signal_remove_file_to_unlink() immediately after doing the rename.
Hmm, I guess that's OK given that we don't process fatal signals immediately but only after we get back to the main loop. > > rename is always atomic, so I'm not sure what the statement about > > atomicity adds here. > > I meant that the whole operation is atomic, as opposed to opening the > pidfile, locking it, and then writing to it, during which > you'd briefly have an empty/half-written pidfile. That said, I agree this > comment is unclear and not particularly useful. I'll remove it. OK, thanks. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
