> I see your point but would argue (in the most > friendly way) that the case you point out would be extremely rare, while > the reverse case is very common.
"Correctness" (in the context of software engineering) doesn't mean doing the right thing in all but the rarest cases; it means doing the right thing in every case. Multiprocessor race conditions are extremely rare, but that doesn't absolve us from putting locks around critical sections in the kernel to guarantee that "rare" becomes "never". Remember mk is not just used to compile stuff. It's a "general tool for describing and maintaining dependencies between files or programs". If there are cases (even extremely rare ones) when mk can finish without establishing all the described dependencies, it's broken. Given the simple low-resolution time stamps currenly supported by the Plan 9 file protocol, ensuring that files are updated correctly may come at a cost of doing some redundant work. Think a bit further outside the box than a single-user computer being used to compile programs. Suppose for example there's a cron script which uses mk to update indices for the lookman(1) command, or to update hash files for ndb(8). What if someone (maybe in another timezone!) happens to be editing a man page or ndb file when the cron job activates. Oops, race condition. Extremely rare like most race conditions, but I for one am happy that mk is robust enough do the right thing when the rare occurrence occurs.
