From mboxrd@z Thu Jan 1 00:00:00 1970 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 08 May 2009 22:10:55 -0400 Subject: [sup-talk] sent source In-Reply-To: <1241702060-sup-3211@entry> References: <1241702060-sup-3211@entry> Message-ID: <1241834800-sup-1443@ntdws12.chass.utoronto.ca> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: