Re: [9fans] mk time-check/slice issue

[Blake McBride <blake@mcbride.name>]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

On Thu, Dec 19, 2013 at 2:15 PM, Richard Miller <9fans@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

[-- Attachment #2: Type: text/html, Size: 5660 bytes --]