Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009: > Currently sup-sync-back just says, "hey, you can use this program > /usr/bin/dotlockfile if you have it" and pushes the details of locking > to that. I think that's at least a vaguely reasonable approach. Ideally > it would be more configurable, would fall back to other locking > programs, etc., but I think it's significantly better than not doing any > locking at all.
...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. > (Eventually these two mbox writers should share the same locking code, > but don't feel obligated to refactor as part of your patch if it's > already getting too hairy.) sup-sync-back could make use of this LockManager too. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting.
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
