Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Date: 7 Jun 2003 12:04:43 -0000
Message-ID: <20030607120443.26597.qmail@icarus.apache.org>
From: trawick@apache.org
To: apr-cvs@apache.org
Subject: cvs commit: apr/locks/unix proc_mutex.c

trawick     2003/06/07 05:04:43

  Modified:    .        CHANGES
               locks/unix proc_mutex.c
  Log:
  When using a temporary file for flock- and fcntl-based mutexes,
  don't let the file be deleted on close.  For flock-based mutexes,
  this corrects a fatal problem, since the file would disappear
  when a program was spawned and cleanup-for-exec was performed,
  and a subsequent attempt to perform child process mutex
  initialization would fail.  For fcntl-based mutexes, this was a
  very minor issue that resulted in a failing unlink() when the
  file was closed, since fcntl lock initialization always removes
  the file immediately.
  
  Revision  Changes    Path
  1.416     +10 -0     apr/CHANGES
  
  Index: CHANGES
  ===================================================================
  RCS file: /home/cvs/apr/CHANGES,v
  retrieving revision 1.415
  retrieving revision 1.416
  diff -u -r1.415 -r1.416
  --- CHANGES	5 Jun 2003 02:29:12 -0000	1.415
  +++ CHANGES	7 Jun 2003 12:04:42 -0000	1.416
  @@ -1,5 +1,15 @@
   Changes with APR 0.9.4
   
  +  *) When using a temporary file for flock- and fcntl-based mutexes, 
  +     don't let the file be deleted on close.  For flock-based mutexes,
  +     this corrects a fatal problem, since the file would disappear 
  +     when a program was spawned and cleanup-for-exec was performed, 
  +     and a subsequent attempt to perform child process mutex 
  +     initialization would fail.  For fcntl-based mutexes, this was a 
  +     very minor issue that resulted in a failing unlink() when the 
  +     file was closed, since fcntl lock initialization always removes 
  +     the file immediately.  [Jeff Trawick]
  +
     *) When writing to pipes with a timeout set, handle the situation
        where the kernel says the pipe is writable but an attempt to
        write <= PIPE_BUF bytes gets EAGAIN.  APR will now write whatever
  
  
  
  1.31      +4 -7      apr/locks/unix/proc_mutex.c
  
  Index: proc_mutex.c
  ===================================================================
  RCS file: /home/cvs/apr/locks/unix/proc_mutex.c,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- proc_mutex.c	19 Apr 2003 02:33:13 -0000	1.30
  +++ proc_mutex.c	7 Jun 2003 12:04:43 -0000	1.31
  @@ -516,7 +516,8 @@
       }
       else {
           new_mutex->fname = apr_pstrdup(new_mutex->pool, "/tmp/aprXXXXXX");
  -        rv = apr_file_mktemp(&new_mutex->interproc, new_mutex->fname, 0,
  +        rv = apr_file_mktemp(&new_mutex->interproc, new_mutex->fname,
  +                             APR_CREATE | APR_WRITE | APR_EXCL,
                                new_mutex->pool);
       }
    
  @@ -526,11 +527,6 @@
       }
   
       new_mutex->curr_locked = 0;
  -    /* XXX currently, apr_file_mktemp() always specifies that the file should
  -     *     be removed when closed; that unlink() will fail since we're 
  -     *     removing it here; we want to remove it here since we don't need
  -     *     it visible and we want it cleaned up if we exit catastrophically
  -     */
       unlink(new_mutex->fname);
       apr_pool_cleanup_register(new_mutex->pool,
                                 (void*)new_mutex,
  @@ -631,7 +627,8 @@
       }
       else {
           new_mutex->fname = apr_pstrdup(new_mutex->pool, "/tmp/aprXXXXXX");
  -        rv = apr_file_mktemp(&new_mutex->interproc, new_mutex->fname, 0,
  +        rv = apr_file_mktemp(&new_mutex->interproc, new_mutex->fname,
  +                             APR_CREATE | APR_WRITE | APR_EXCL,
                                new_mutex->pool);
       }