On Feb 1, 2008 1:52 PM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > 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?
No, that would imply that one hung fish process could hang all fish processes. set -U waits until fishd replies that it has the notification. Every fish command asks fishd for new values before executing. > 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? I would settle for some other much simpler promise that will also enable you to make reasonable assumptions about concurrency. I think we need _something_ something. > 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? That's not very useful unless you can prove that it is always unnoticable, e.g. at every load level on any number of CPU:s, etc. > > 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 would very much like for some method to ask that all uvars set by other processes are visible. This method can be expensive and I could accept it if is only invoked manually on a per request basis. There is another question, namely automatic notifications. If an uvar changes value, then all shells should be notified asap, specifically this should happen to interactive shells that are waiting for input from the user. This is needed to have nice event handlers that trigger on universal variable updates, like we have today. Axel > > 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
