On Fri, Jul 06, 2007 at 09:03:31PM +0100, Joe Orton wrote:
> On Fri, Jul 06, 2007 at 07:53:19PM +0200, Stefan K??ng wrote:
> > Well, I'm not that familiar with the neon code, but from what I can see
> > it should be thread safe. But just to be sure, I've cc'ed Joe Orton. I
> > guess he's the one who could clear this issue up.
> >
> > Joe, is the ne_sock_exit() function thread-safe? If not, then when
> > should this be called?
>
> ne_sock_exit() destroys any process-global state created by
> ne_sock_init(), so no, it's not thread-safe. The OpenSSL locking
> callbacks are one case of such process-global state - the other case is
> in the use of the Win32 socket/SSPI libraries.
>
> ne_sock_exit() should only be used (if at all) when you know there will
> be no subsequent use of neon within the process by the caller. AFAIK
> this isn't true in the ra_dav session cleanup, since there are two
> sessions and there will be another call to ne_session_destroy().
>
> (Looking at the code, ra_dav should really just call ne_sock_init() once
> in svn_ra_dav__init, I think; it's unnecessary/wrong to call it each
> time an RA session is opened.)
>
I'm leaning towards "wrong", since ne_sock_init doesn't serialize its
access to the init_state counter.
I wonder if this is the root cause of the double-free problem that Dan
Christian described earlier:
http://svn.haxx.se/dev/archive-2007-05/0182.shtml
Dan, care to try moving the call to ne_sock_init out of
svn_ra_neon__open and into svn_ra_neon__init?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 7 17:22:11 2007