[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: Patrick Mayweg <mayweg_at_qint.de>
Date: 2005-11-15 07:40:09 CET

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.

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.

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.


Garrett Rooney wrote:

>On 11/14/05, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
>>Thanks. (HACKING doesn't actually define what a -0 means, or whether
>>it's a veto.)
>-0 is more of a "I'm not sure this is a good idea" kind of thing.
>>In which case, I'll wait until later tomorrow to see if anyone has any
>>objections, then merge it into the 1.3 branch. As I understand it,
>>a change exclusively under bindings (like this one) only requires a
>>single +1 to merge.
>Actually, you need one more vote to merge, someone with commit access
>to that part of the tree needs to vote at least +0, which would leave
>you with the required one +1 and one +0 vote. If I have a chance I'll
>try to go over all this stuff once more later today, so I can at least
>give you that ;-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 15 07:40:58 2005

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