On Thu, Nov 6, 2008 at 9:19 AM, Blair Zajac <blair_at_orcaware.com> wrote:
> Ben Collins-Sussman wrote:
>> On Thu, Nov 6, 2008 at 1:35 AM, David Glasser <glasser_at_davidglasser.net>
>>> There's a lock around appending to the proto-rev file, yes. And it
>>> does write a bunch of little files for noderevs, directory listings,
>>> and props, and gloms them on at finalization time, yes. But there are
>>> no locks around editing the little files themselves; so for example,
>>> if concurrent processes make two files in a directory at the same
>>> time, there can be a race condition and only one will end up in the
>>> listing. This situation isn't possible if you only access a
>>> transaction from a single process (say, via the commit editor).
>> But if all writes go through a single process, that sort of defeats
>> the goal of saturating the bandwidth with parallel PUTs. Maybe it
>> would be a worthy goal to make FSFS safe? I know it's something we'll
>> have to do for libsvn_fs_bigtable.
> Having the ability to expose an svn_txn_fs through an HTTP interface would
> be very useful. I needed this functionality for an application we're
> writing and ended up writing my own RPC layer on top of svn_fs.h to
> accomplish this.
> So I'd rather not see an HTTP interface that you begin a txn, push and
> commit all in one step.
> I haven't looked at the mod_dav_svn code, but does it maintain a pool of
> svn_txn_t's where users of the svn_txn_t's checkout and get one?
> When I looked at the fsfs code, there's locking in a single svn_txn_t, but
> if you have a multithreaded application that has multiple svn_txn_t's open
> for the same transaction, then there's nothing protecting the transaction
> from concurrent writes. The fcntl() locks don't protect between multiple
> threads in the same process and since you have two or more svn_txn_t's, they
> don't synchronize on the same mutex.
No, the things that are protected at all do work across svn_txn_t's,
because they use mutexes which are shared in a structure stored in the
global pool's shared userdata.
But not everything that should be protected is.
David Glasser | email@example.com | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 18:35:40 CET