You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/05/31 06:37:55 UTC
ra_svn and thread-safety/initialization
I know a number of sites, including Collabnet, would find ra_svn more
acceptable if it sported authentication options other than "give
developers accounts and tunnel over ssh." I'm not sure how much of a
1.0 priority this should be (we have ra_dav, after all), but I know
some people would appreciate it.
Unfortunately, there's a bit of a stumbling block. I was planning to
integrate Cyrus SASL as an optional dependency, which would get us a
whole pile of authentication types (CRAM-MD5 and GSSAPI/KRB5 and maybe
SRP are probably the most notable; I expect that STARTTLS would become
an option in the future), but it uses a dynamically loaded plugin
architecture. This means it needs to run an initialization step once,
since you can't dlopen() libraries multiple times. (Perhaps I'm wrong
about that, but regardless, Cyrus SASL documents that it wants to run
an initial step once before any other calls are made, or it won't be
thread-safe. I'm also supposed to hand it mutex-locking callbacks for
it to be thread-safe.)
My problem is that APR doesn't provide any kind of locking to ensure
that an initialization step is performed once. It has mutexes, but no
static mutex initializers. It has the concept of a "once", but again,
there's no static initializer for a once.
The options I see are:
* Introduce an svn_initialize() which applications have to call
instead of (or in addition to) apr_initialize(), before forking
any threads. Have it invoke initializers for each ra layer, and
make ra_svn provide one which intializes the SASL library.
* Implement our own SASL mechanisms and just accept the bulk. (We
wouldn't be the first; Evolution does this, for instance.)
Without writing too much code, I could probably implement CRAM-MD5
and maybe STARTTLS (using OpenSSL, of course).
* Rip out the SASL stuff in the ra_svn protocol (or leave in the
stubs we have, although that might be confusing in the long run)
and provide a tunnel agent which uses SASL for authentication.
* Keep the current protocol, but do the SASL stuff in a subprocess
(without using the tunnel-agent mechanism). If you don't have
thread-safety, there's always processes.
* Do nothing.
Opinions? I'm not sure how to best balance architectural cleanliness
with administrative convenience. Library integration seems the most
transparent to the adimnistrator, but provides the most architectural
headaches.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > * Introduce an svn_initialize() which applications have to call
> > instead of (or in addition to) apr_initialize(), before forking
> > any threads. Have it invoke initializers for each ra layer, and
> > make ra_svn provide one which intializes the SASL library.
>
> I seem to remember that we had other reasons for wanting to create
> svn_initialize(). I remember talking with someone about this, that
> such a function would call apr_initialize() internally, and do other
> important things as well. Does this ring a bell with anyone?
Here's a little something:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=25407
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > * Introduce an svn_initialize() which applications have to call
> > instead of (or in addition to) apr_initialize(), before forking
> > any threads. Have it invoke initializers for each ra layer, and
> > make ra_svn provide one which intializes the SASL library.
>
> I seem to remember that we had other reasons for wanting to create
> svn_initialize(). I remember talking with someone about this, that
> such a function would call apr_initialize() internally, and do other
> important things as well. Does this ring a bell with anyone?
Yep. I remember this. I'll see if I can dig up the archive.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Greg Hudson <gh...@MIT.EDU> writes:
>
>> * Introduce an svn_initialize() which applications have to call
>> instead of (or in addition to) apr_initialize(), before forking
>> any threads. Have it invoke initializers for each ra layer, and
>> make ra_svn provide one which intializes the SASL library.
>
> I seem to remember that we had other reasons for wanting to create
> svn_initialize(). I remember talking with someone about this, that
> such a function would call apr_initialize() internally, and do other
> important things as well. Does this ring a bell with anyone?
The svn_config_ensure stuff.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> * Introduce an svn_initialize() which applications have to call
> instead of (or in addition to) apr_initialize(), before forking
> any threads. Have it invoke initializers for each ra layer, and
> make ra_svn provide one which intializes the SASL library.
I seem to remember that we had other reasons for wanting to create
svn_initialize(). I remember talking with someone about this, that
such a function would call apr_initialize() internally, and do other
important things as well. Does this ring a bell with anyone?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2003-06-03 at 01:24, Branko Čibej wrote:
> Can we use libgsasl at all? It's GPL.
... oh. I didn't even think about that. Good point. Fortunately, I
hadn't gotten started yet.
> Grrrr, I see this question more and more often in connection open source
> projects that aren't licensed under the GPL -- especially those that use
> a BSD-like license. Looks like FSF & friends are actually *hindering*
> free software development with their anal attitude. And don't let me
> even start about GFDL.
I'm afraid this debate is as old as the winds; not much we can do about
it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
> Can we use libgsasl at all? It's GPL.
Yes, if you switch the license of Subversion to GPL ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
> * There is another implementation, libgsasl, which does not have the
>same problems; it uses a global context for initialization and
>destruction as well as a per-connection context. The implementation may
>not be as mature as Cyrus's, but it may be worth a try. (gnus is using
>libgsasl via its command-line "gsasl" front end by default now, so it's
>experiencing some field testing.)
>
Can we use libgsasl at all? It's GPL.
<rant>
Grrrr, I see this question more and more often in connection open source
projects that aren't licensed under the GPL -- especially those that use
a BSD-like license. Looks like FSF & friends are actually *hindering*
free software development with their anal attitude. And don't let me
even start about GFDL.
</rant>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2003-06-13 at 10:19, Joe Orton wrote:
> > * On reflection, Cyrus SASL is not acceptable for use within a
> > library, because it uses global state. Subversion would conflict with
> > any other library or any application which also uses the Cyrus SASL
> > library.
> Sorry to jump in late: OpenSSL has exactly the same problem - it's
> probably worth solving this with an svn_initialize() or whatever for
> ra_dav too and just documenting the possible conflicts.
I think Cyrus is worse; it doesn't just require a single-threaded
initialization function, it uses a global callbacks structure.
(But if we currently have a thread-safety problem in ra_dav, we should
probably address it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Mon, Jun 02, 2003 at 01:07:50AM -0400, Greg Hudson wrote:
> Here is my current thinking on the issue:
>
> * On reflection, Cyrus SASL is not acceptable for use within a
> library, because it uses global state. Subversion would conflict with
> any other library or any application which also uses the Cyrus SASL
> library.
...
Sorry to jump in late: OpenSSL has exactly the same problem - it's
probably worth solving this with an svn_initialize() or whatever for
ra_dav too and just documenting the possible conflicts.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Greg Hudson <gh...@MIT.EDU>.
Here is my current thinking on the issue:
* On reflection, Cyrus SASL is not acceptable for use within a
library, because it uses global state. Subversion would conflict with
any other library or any application which also uses the Cyrus SASL
library. I've sent mail to the IETF working group working on
standardizing C-language bindings for SASL, in hopes that this might get
addressed some day.
* There is another implementation, libgsasl, which does not have the
same problems; it uses a global context for initialization and
destruction as well as a per-connection context. The implementation may
not be as mature as Cyrus's, but it may be worth a try. (gnus is using
libgsasl via its command-line "gsasl" front end by default now, so it's
experiencing some field testing.)
* If that doesn't work out, I'll probably look into solutions using
subprocesses (either using the tunnel agent mechanism or some new
"authentication agent" mechanism which would preserve the existing
protocol).
So, I think I've ruled out the option which would require a static
initializer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2003-06-01 at 01:52, rbb@rkbloom.net wrote:
> Two things. 1) APR not having a static initializer that you can use is a
> pretty major bug that makes apr_thread_once a lot less useful. It's my
> fault, I wrote the function originally, and I didn't think that through.
> It should be a relatively easy patch to create one. That would be one way
> to resolve the problem.
On Unix, apr can use PTHREAD_ONCE_INIT. On win32, it looks like apr can
use all-zeros. On OS2, it looks trickier.
> 2) I haven't read the ra_svn code, so I am just spitballing here, but
> there must be some place that you can call apr_thread_once_init before
> you create threads. If there isn't, then you will need to modify APR to
> include a static initializer.
Right now, Subversion does not have a library initialization function.
And ra_svn is supposed to be absolutely invisible to the application (it
hides beneath the covers of libsvn_ra), so there's no way I can demand
that applications call some special ra_svn initializer before creating
threads.
We can certainly change the lack of a library initializer, but I'm not
certain it's a great idea. It was one of the options I presented in my
initial mail.
> Right now I feel like a moron for leaving that out. I wonder how many
> other places need a static initializer that I didn't think about.
Mutexes and condition variables traditionally have static initializers
(they do in POSIX.4, anyway), but I don't know if all of APR's target
platforms make them possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by rb...@rkbloom.net.
On 31 May 2003, Greg Hudson wrote:
> On Sat, 2003-05-31 at 13:16, rbb@rkbloom.net wrote:
> > Why can't you use apr_thread_once? Just put the initialization steps in a
> > function that is called through apr_thread_once, and you will be
> > guaranteed that the function will be called one time and only one time.
>
> It looks like I have an initialize an apr_thread_once_t with
> apr_thread_once_init(). I can't do that each time svn_ra_svn_init() is
> called, so where can I do it?
Two things. 1) APR not having a static initializer that you can use is a
pretty major bug that makes apr_thread_once a lot less useful. It's my
fault, I wrote the function originally, and I didn't think that through.
It should be a relatively easy patch to create one. That would be one way
to resolve the problem.
2) I haven't read the ra_svn code, so I am just spitballing here, but
there must be some place that you can call apr_thread_once_init before
you create threads. If there isn't, then you will need to modify APR to
include a static initializer.
Right now I feel like a moron for leaving that out. I wonder how many
other places need a static initializer that I didn't think about.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-05-31 at 13:16, rbb@rkbloom.net wrote:
> Why can't you use apr_thread_once? Just put the initialization steps in a
> function that is called through apr_thread_once, and you will be
> guaranteed that the function will be called one time and only one time.
It looks like I have an initialize an apr_thread_once_t with
apr_thread_once_init(). I can't do that each time svn_ra_svn_init() is
called, so where can I do it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_svn and thread-safety/initialization
Posted by rb...@rkbloom.net.
On Sat, 31 May 2003, Greg Hudson wrote:
> My problem is that APR doesn't provide any kind of locking to ensure
> that an initialization step is performed once. It has mutexes, but no
> static mutex initializers. It has the concept of a "once", but again,
> there's no static initializer for a once.
Why can't you use apr_thread_once? Just put the initialization steps in a
function that is called through apr_thread_once, and you will be
guaranteed that the function will be called one time and only one time.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org