rooneg@gmail.com wrote on 11/14/2005 03:52:45 PM:
> On 11/14/05, Mark Phippard <markp@softlanding.com> wrote:
>
> > I do not believe that SVNClientSynchronized is synchronizing on a
specific
> > instance of the class. If it were, then it wouldn't be thread safe at
> > all. It is synchrnonizing on a static instance of the .class which I
> > believe will apply to all instances of the class and therefore all
> > threads.
> >
> > We use SVNClientSynchronized in Subclipse.
>
> Ok, but is it absolutely 100% required that any multithreaded code
> that uses any part of JavaHL go through the SVNClientSynchronized
> class? If so, that will prevent this problem, but if not it can still
> occur.
>
> If that is the case, btw, it seems rather odd to me. Why can't there
> be multiple instances of SVNClient doing totally unrelated things at
> the same time? There doesn't seem to be any fundamental reason that
> they should be using any shared state.
I do not think it is at all unreasonable for a Java library to declare its
thread-safety. I have seen several that flat-out say they are not thread
safe. I do not see the problem with JavaHL providing a thread-safe and
non thread-safe version of the interface. It is hardly a burden to change
your code from:
SVNClientInterface client = new SVNClient();
to
SVNClientInterface client = new SVNClientSynchronized();
If you need thread safety.
All this being said, it stinks that a fix for a JVM crash might not get
into the next release candidate over issues that could have been brought
up any time over the past couple of years. Yes, it would be great if
Patrick were around and could vote for his own patches, but apparently he
isn't. Is there no one else capable of reviewing and voting on these? In
the end it is mostly just C++ code and is either valid or not.
I can verify that the Java part of the code all looks good and also
Patrick added two tests to the test suite that test the re-entry
situation.
Finally, as I said before and know you are aware I can vouch that this
patch addresses the two JVM crash scenarios in Subclipse (which Patrick's
new tests also would exercise).
Our only workaround to these problems in Subclipse are to avoid any
re-entry situations. This means writing our own Java versions of
getAdminDirectory() and isAdminDirectory() (which I am fine with) and not
providing the UI option of cancelling an operation (which I wish we could
add).
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 22:14:09 2005