[MERGE] repository write groups

Martin Pool mbp at sourcefrog.net
Tue Jul 31 04:16:12 BST 2007


On 7/30/07, Robert Collins <robertc at robertcollins.net> wrote:

> > Is it just an entirely optional hint that some related writing is
> > being done?  Or is the caller making a promise to the repository, or
> > vice versa?
>
> The caller is not able to insert data outside the write group, so the
> repository is promising to allow data insertion during the group.

Great, so say that!  "You are only allowed to insert data into a
repository during a write group", if that's the case.

> On some repositories a write lock is a mutex, because of the performance
> impact of doing reads after a write has occured - e.g. weaves, where
> writing reorganises large amounts of data. On others, like the one I'm
> working on, or on svn, the write lock can become fictional, with actual
> mutex's occuring during data insertion. E.g. I plan for
> commit_write_group on pack repositories to be something like:
> write out indices
> take out a physical lock on the repository
> allocate a name for the new pack
> rename the pack and indices into place
> release the physical lock

So it does sound a bit like this is really the write group, and it
should implicitly take (or increment) a write lock if necessary.  "I'm
starting writing... I'm done."

> > Not closing files (even in failure cases, iirc) caused pain for people
> > testing on Windows and I don't see why this is any different.
>
> not closing files can cause errors in success cases; and also can have
> the file object open in the traceback stack frames in error cases. This
> is different because there are no physical resources kept open to cause
> operating system level errors.

Yes there are, the lock file held by WT4.

And just generally, I don't think we want to rely on being able to
delete a wt while it's locked.

-- 
Martin



More information about the bazaar mailing list