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

Re: r17214, JavaHL thread local storeage and reentrant calls

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2005-11-15 20:24:35 CET

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.



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

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