Re: [9fans] Plan9 - the next 20 years

["J.R. Mauro" <jrm8005@gmail.com>]

On Sat, Apr 18, 2009 at 9:50 AM, erik quanstrom <quanstro@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.