The strategy sounds resonable to me.<br><br>However from a high level view wouldn't it make more sense to provide 2 APIs to svk itself:<br><br>1) Access to and locking of the depotmap<br>2) Access to and locking of checkout paths
<br><br>This split would make it easier to refactor the checkout code to store the Data::Hierarchy for a given working copy locally in that working copy (f.e. in a SVK or .svk dir) while keeping the depotmap and depots where they are today.
<br><br>Michael<br><br><br><div><span class="gmail_quote">On 8/18/06, <b class="gmail_sendername">David Glasser</b> <<a href="mailto:glasser@mit.edu">glasser@mit.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So what I'm trying to implement for SVK's locking strategy (which will<br>be added to internal pod docs) follows. Note that neither SVK nor the<br>patch I just sent fully implements this; I have another patch that I<br>think does but I'd like to test it out on Win32 first.
<br><br>Do people think this is a good locking strategy?<br><br>SVK Locking strategy:<br><br>Note: this is *not* about "mirror locks" or "Subversion locks": this<br>is about locking access to SVK's statefile ($SVKROOT/config) and
<br>checkouts.<br><br>SVK has an application-level "giant" lock, which is a file<br>($SVKROOT/lock). "Holding" the giant lock means having an open<br>filehandle to it, locked exclusively. The process that holds the
<br>giant lock writes its PID into the giant lock file for informational<br>purposes. The giant lock controls all access to the statefile; SVK<br>should never read or write the statefile without holding the giant<br>lock.
<br><br>When an SVK command is executed, the following sequence of events<br>happens (note that commands like "svk help" and "svk --version" which<br>will never need access to the statefile or checkout are special-cased
<br>to not do any locking):<br><br>* Acquire the giant lock; if this fails for several seconds, die.<br><br>* Read the statefile into memory.<br><br>* Call the command's parse_args method.<br><br>* Call the command's lock method. The command can choose one of three options:
<br><br>** Commands which need to make drastic changes to the statefile<br> (including depotmap changes) should call the keep_giant method;<br> this will make SVK hold the giant lock for the entire command. This<br> should be avoided if possible, especially for commands which take a
<br> non-constant amount of time.<br><br>** Commands which need to access a checkout path (either the actual<br> checkout on disk or its record in the Data::Hierarchy object in the<br> statefile) should call lock on their XD (either directly or through
<br> something like lock_coroot); they may call this on multiple paths<br> if they wish. This dies if the statefile that they have already<br> read in indicates that another process has locked those checkout<br> paths. Otherwise, it marks those paths as locked to this process in
<br> the in-memory Data::Hierarchy of the XD.<br><br>** Commands which don't depend on checkout paths can just do nothing.<br><br>* If the command's locking phase locked any checkout paths, write the<br> statefile out to disk.
<br><br>* Unless the command made a keep_giant call, drop the giant lock.<br><br>* Call the command's run method.<br><br>* If the command was keeping the giant lock, write out the statefile,<br> drop the giant lock, and exit.
<br><br>* If the command had locked any paths, get the giant lock, read in the<br> statefile, merge in any changes to the Data::Hierarchy object *in<br> locked paths only* that the command made, write out the statefile,
<br> and drop the giant lock.<br><br><br>--dave<br><br><br>--<br>David Glasser | <a href="mailto:glasser@mit.edu">glasser@mit.edu</a> | <a href="http://www.davidglasser.net/">http://www.davidglasser.net/</a><br>_______________________________________________
<br>svk-devel mailing list<br><a href="mailto:svk-devel@bestpractical.com">svk-devel@bestpractical.com</a><br><a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
</a><br></blockquote></div><br>