Reformatted excerpts from Ben Walton's message of 2009-05-08: > ...Ok, what about implementing the dotlockfile functionality inside a > LockManager singleton? I'm thinking about something that would accept > a list of required locks before allowing read and write. It would > then provide with_readlock(file, &block) and with_writelock(file, > &block) methods that obtain required locks and yield to the caller to > do the actual work.
That sounds good to me and is very much in the spirit of the current Sup codebase. I'd like to also have a non-yield mechanism (e.g. #lock and #unlock methods), similar to the interface Mutex exposes, because sometimes it's irritating to use the block form, but that's icing on the cake. > sup-sync-back could make use of this LockManager too. Yes, definitely they should all share the same code path. -- William <[email protected]> _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
