> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe_at_rowe-clan.net]
> Sent: vrijdag 6 december 2013 18:24
> To: Stefan Fuhrmann
> Cc: Bert Huijben; APR Developer List; Stefan Fuhrman; Philip Martin;
> Subversion Development
> Subject: Re: Race condition in APR_DECLARE_LATE_DLL_FUNC()
> implementation
>
> On Fri, 6 Dec 2013 16:44:52 +0100
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
>
> > On Fri, Dec 6, 2013 at 6:05 AM, William A. Rowe Jr.
> > <wrowe_at_rowe-clan.net>wrote:
> >
> > > On Thu, 5 Dec 2013 15:01:05 +0100
> > > "Bert Huijben" <bert_at_qqmail.nl> wrote:
> > >
> > > > I think the dll load function should be converted to a more stable
> > > > pattern, that properly handles multiple threads. And perhaps we
> > > > should just assume a few more NT functions to be alsways there
> > > > instead of loading them dynamically.
> > >
> > > This is possible with the 'mandatory' call to apr_init, but I think
> > > the existing pattern should persist for those who don't like to
> > > call the initialization logic.
> > >
> >
> > We currently call apr_initialize() before spawning threads or doing
> > anything other APR. What else do we need to become thread-safe
> > under Windows?
>
> Working on a patch. Simply, we just need an _initialize hack that
> triggers this lookup for each internally required (or not-present) fn.
It is also possible to rewrite the functions to do an atomic replace of the
function pointer, which makes them safe for multithreaded usage. (Same
pattern as we use in Subversion for atomic initializations or even simpler
variants as it is safe to do the same LoadLibraryXX() and GetProcAddress()
in multiple threads at once, via the Windows loader lock.)
But as far as I can see all the functions are always available on Windows XP
and later (and the others are not even used by APR and APR-Util), so I'm not
really sure if we should really spend more time on this.
Bert
Received on 2013-12-06 19:15:07 CET