apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject cvs commit: apr/threadproc/win32 thread.c
Date Sat, 01 Sep 2001 16:48:58 GMT
rbb         01/09/01 09:48:58

  Modified:    threadproc/win32 thread.c
  Log:
  One more iteration on apr_thread_once on Windows.  Now we use
  InterlockedExchange, and we don't have the wrapping problem, so
  we can also remove the quick escape hatch.
  Submitted by:	Sander Striker <striker@apache.org>
  
  Revision  Changes    Path
  1.39      +1 -13     apr/threadproc/win32/thread.c
  
  Index: thread.c
  ===================================================================
  RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- thread.c	2001/09/01 07:29:07	1.38
  +++ thread.c	2001/09/01 16:48:58	1.39
  @@ -231,19 +231,7 @@
   APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
                                             void (*func)(void))
   {
  -    /* Quick escape hatch, and bug fix.  The InterlockedIncrement
  -     * call is just incrementing a long int, so it has the potential
  -     * to wrap.  Very unlikely, but still, that would be an almost
  -     * impossible bug to hunt.  With this, we might see one or two
  -     * calls to InterlockedIncrement, but never enough to wrap the
  -     * long int.  This also saves us a kernel call for most calls to
  -     * this function.
  -     */
  -    if (control->value) {
  -        return APR_SUCCESS;
  -    }
  -    InterlockedIncrement(&control->value);
  -    if (control->value == 1) {
  +    if (!InterlockedExchange(&control->value, 1)) {
           func();
       }
       return APR_SUCCESS;
  
  
  

Mime
View raw message