On Jan 30, 2008 11:13 PM, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > On Jan 24, 2008 11:56 PM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > > If communicating through files is good enough remotely, it should be > > good enough locally. > > I want to implement it (hopefully this weekend) and see how well it works. > > Do you know anything that I missed which makes it a bad idea? Why is > > fishd needed? > > Currently, fishd promises that when one command has finished > executing, any new command that start executioin on _any_ fish > instance will see the new value. I'm not usre how you could make that, > or another reasonably good promise on notification speed, without > degrading performance significantly. Keep in mind that this holds true > also for builtin commands. > So a set -U waits until all other fish instances confirm that they have seen the notification? OK, this is obviously a strong promise that is hard to replicate using NFS. Without connecting to a centralized server, I don't even see how the notion of "all other fish instances" is well-defined.
The question is, why do we need such a strong promise? OK, so suppose I set a uvar on one terminal and immediately run a command depending on it on another terminal. True, I would like the other fish to see the new value about this. If this is the same computer, I would be strongly surprised if it didn't. Over NFS, I should be used to a small delay between computers (I create a file but don't see it for several seconds, such things). Since most shell work involves files, I don't think the user would care if uvars don't behave any better. > If you can figure out a reasonable set of tradeoffs using a file as a > backend, a basic file should be just as good. > Locally, I'd like to retain you promise. Or perhaps prove that the delay is very unnoticable? Remotely, I think best-effort + A[C]ID should suffice: * Isolation: each command sees a uvar either as it was between the change or after. * Atomicity: if the writing fish crashes, the variable is either changed or not. * Durability: if the "set" command complete, the variable will be changed. * [no Consistency]: no promises about relation between multiple variables. Doesn't seem relevant. By "best-effort" I mean notification will happen in the best time achievable with file system operations. We don't just let it rot in some cache for minutes. Perhaps an ordering promise should also be given to reduce surprises (if B is set after A, it's impossible to see the change in B before you see the change in A). Not sure if this has any practical importance. I'm putting the implementation on hold until we decide on acceptable (or not) promises and I learn some more about NFS semantics. -- Beni Cherniavsky <[EMAIL PROTECTED]> (I read email only on weekends) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
