From mboxrd@z Thu Jan 1 00:00:00 1970 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 09 May 2009 06:01:04 -0700 Subject: [sup-talk] sent source In-Reply-To: <1241834800-sup-1443@ntdws12.chass.utoronto.ca> References: <1241702060-sup-3211@entry> <1241834800-sup-1443@ntdws12.chass.utoronto.ca> Message-ID: <1241873892-sup-9543@entry> 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