apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: cvs commit: apr/threadproc/win32 thread.c
Date Sat, 01 Sep 2001 07:24:28 GMT
On Friday 31 August 2001 22:39, William A. Rowe, Jr. wrote:
> > rbb         01/08/31 22:10:23
> >
> >   Modified:    include/arch/win32 threadproc.h
> >                threadproc/win32 thread.c
> >   Log:
> >   Implement apr_thread_once for Windows.
> >
> >   +APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
> >   +                                          void (*func)(void))
> >   +{
> >   +    InterlockedIncrement(&control->value);
> >   +    if (control->value == 1) {
> >   +        func();
> >   +    }
> >   +    return APR_SUCCESS;
> >   +}
>
> This looks like a possible bug - control->value -could- someday wrap
> (especially if it wasn't called once per thread, but once per some
> operation!)  What if we
>
>     if (control->value)
>         return APR_SUCCESS;
>
> first, which will start null, so several folks might
> fall in (incrementing to perhaps 2, possibly 10, doubtfully 100).  But
> everyone hitting that line afterwards gets a fast escape, we're assured it
> was done without the kernel call and without the chance for wrapping.

We could do that.  I don't really like the idea of doing one extra if each time this
is called, but it does save a kernel call.  Okay, I'll add it right now.  :-)

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message