> I think that passing "w+" as the mode to fopen() is now a mistake, > because it will cause us to truncate an existing file to zero length. > That's bad if some other process already opened the file and obtained a > lock on it, because we just erased its pid. >
Good catch, thanks. I'll work something out. > > 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. 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. I'll send a new version out shortly. Thanks for the review. Ethan
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
