On Sat, Apr 18, 2009 at 9:50 AM, erik quanstrom <quans...@quanstro.net> wrote: >> > * you can get the same effect by increasing the scale of your system. >> > >> > * the reason conventional systems work is not, in my opinion, because >> > the collision window is small, but because one typically doesn't do >> > conflicting edits to the same file. >> > >> > * saying that something "isn't likely" in an unquantifiable way is >> > not a recipie for success in computer science, in my experience. >> > >> > - erik >> > >> >> I don't see how any of that relates to having to do more work to >> ensure that C/R and process migration across nodes works and keeps >> things as consistent as possible. > > that's a fine and sensible goal. but for the reasons above, i don't buy this > line of reasoning. > > in a plan 9 system, the only files that i can think of which many processes > have open at the same time are log files, append-only files. just reopening > log file would solve the problem. > > what is a specific case of contention you are thinking of? > > i'm not sure why editor is the case that's being bandied about. two users > don't usually edit the same file at the same time. that case already > does not work. and i'm not sure why one would snapshot an editing > session edit the file by other means and expect things to just work out. > (and finally, acme, for example, does not keep the original file open. > if open files are what get snapshotted, there would be not difference.) > > - erik > >
Ron mentioned a bunch before, like /etc/hosts or a pipe to another process, and I would also suggest that things in /net and databases could be a serious problem. If you migrate a process, how do you ensure that the process is in a sane state on the new node? I agree that generally only one process will be accessing a "normal" file at once. I think an editor is not a good example, as you say.
