Re: Communication of CHANGES

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
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org