[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Communication of CHANGES

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-11-28 22:00:05 CET

Bicking, David (HHoldings, IT) wrote:

>> If you expect multiple GUI clients to be
>> concurrently running and always display the same info you are
>> going to need a lot of synchronization and locking gunk that
>> doesn't seem to belong in a core api - and if it doesn't do
> Why does having two clients to a file automatically mean concurrency
> problems? There's only a problem if they try to write to it at the same
> time.

I thought I was replying to a complaint about two different GUI's
showing their cached status information out of sync with each other.
That's a concurrency problem.

> That's not going to happen, since users have to request an update
> manually.

I can hit buttons in two windows before a command can complete.

> I think the effort necessary to cause a concurrent write is
> greater than the desire to do it just to break it. Worse case scenario,
> a simple blocking lock serializes the access, so the file is updated
> twice.

And you need to notify other watchers when the contents change if you
want the displays to be the same.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 28 21:59:45 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.