On Thu, Dec 19, 2013 at 2:15 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> > 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. > I see your point, and agree. I suppose I have been arguing for an _option_ that would assist one person working in one tree at a time - a common but not utterly common situation. Also, see my earlier point about fast, prior dependencies unnecessarily triggering very time consuming dependencies. Having been envolved with projects that take 4 hours to build, this could be very significant. Again, the _option_ would help a great deal. Thanks. Blake
