> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
>
> 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.
And I thought we were discussing the merits of the as yet not
implemented single cache maintained by Subversion, as opposed to the
already known to be a problem scenario of multiple caches maintained by
individual clients. I guess I got my wires crossed.
>
> > 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.
So you're saying that you can and WILL click "update" menu items in two
different GUI's within 1/2 second time? Why would you do that? I
thought the idea was to do less work, not more. I guess I was wrong
when I said the effort necessary is greater than the desire to do it
just to break it. I stand corrected. Regardless, as I said earlier, a
simple blocking lock on the appropriate function eliminates that problem
at the cost of redundant retrieval.
>
> And you need to notify other watchers when the contents
> change if you want the displays to be the same.
Or, the watchers might poll the cache file on their own at certain
intervals (like when the window is pulled to the front), which would be
much easier and more logical.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
--
David Bicking
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 14:08:21 2007