On 11/14/05, Patrick Mayweg <mayweg@qint.de> wrote:
> Hi Everyone,
> unfortunately this discussion started in a time, where I normaly do not
> sit in front of a computer. That why I am joining so late.
No worries, everyone gets busy from time to time.
> I did not vote for my change, because I have difficulty to commit since
> I am working at a customers site. I also had to work thru the last
> weekend and simply forgot to it then. I think the change is an
> improvment for 1.3 and should go into 1.3.
>
> SVNClientSynchronized synchronizes on its class object, which can only
> exists once per class loader. It should be changed to the SVNClient
> class object, because that can only exists once per JVM. If you keep
> both classes in one Jar, that is not a real problem. But that is nothing
> new. On the other hand, using synchronization prevents only other
> threads to access something. It does not prevent reentracy.
>
> I wrote SVNClientSynchronized in the first place, because I did see any
> statement about the subversion core libraries reentrant. So if any
> problems arise, it should be easy to switch a thread safe version.
For what it's worth, the Subversion libraries internally are supposed
to be thread safe. Assuming you are using separate context objects
(i.e. if you're calling a client library function in two separate
threads you need two separate svn_client_ctx_t objects, similar rules
apply for other state that gets passed into subversion functions) you
should be fine.
> I will change JavaHL, so that JNIThreadData will no longer be stored in
> thread local storage but passed as parameter in almost all methods and
> put it into the batons. So that every call into the native library will
> keep its JNIEnv, no matter how the JVM schedules the java/native thread.
> But this is major change. I will not have time to do that for 1.3 and I
> do not think it should go 1.3 anyway.
That seems best, but in the meantime the current change should be fine for 1.3.
Thanks,
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 15 20:26:57 2005