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.
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
