From mboxrd@z Thu Jan 1 00:00:00 1970 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 07 May 2009 17:57:22 -0400 Subject: [sup-talk] sent source In-Reply-To: <1241702060-sup-3211@entry> References: <1241702060-sup-3211@entry> Message-ID: <1241733359-sup-131@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009: > Reformatted excerpts from Ben Walton's message of 2009-05-06: > > The next option is to play with locks, but that's not straight forward > > at all. > > This is my favorite option, because sup-sync-back also has to do mbox > locking, so I don't think we can avoid the issue in general. Ok. This is the direction I'll go. This will be the most difficult part of the whole thing. > 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. Wouldn't it be nicer to handle this internally? > (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.) Ok. 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: