httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker pod.c
Date Fri, 21 Mar 2003 17:21:06 GMT
At 10:23 AM 3/21/2003, Joe Orton wrote:
>In the r1.57 filedup.c change, a cleanup is registered for the "new"  
>fd coming out of apr_file_dup2(), which wasn't happening previously.  
>I'm guessing that this cleanup is closing fd 2 when pconf is cleared, or
>something like that.

Clarify this; it's true that 1.56 didn't register a child cleaup for the dup2()
flavor... it's also true that 1.56 and prior never *killed* an existing file
cleanup.  Having (or not having) a cleanup for dup2() altogether depended
upon what was done with the target file prior to calling dup2().

A graphic might help

Old behavior (1.56 and prior):

  apr_file_dup2(new, old)
    \-> replace new->filedes with dup2()ed copy of old->filedes

  apr_file_dup(*new, old)
    \-> initialize new->filedes with dup(old->filedes)
          \-> Register cleanup for (new)

New behavior (1.57):

  apr_file_dup2(new, old)
    \-> Kill (existing?) cleanup for (new)
       \-> replace new->filedes with dup2()ed copy of old->filedes
          \-> Register cleanup for (new)

  apr_file_dup(*new, old)
    \-> initialize new->filedes with dup(old->filedes)
       \-> Register cleanup for (new)

So instead of shaking the dice of 'is there already a cleanup?', dup2()
flavor now assures we kill the old and register the new cleanup.

Another, perhaps more significant change was the change with 1.59
of both dup() and dup2()...

  -    (*new_file)->flags = old_file->flags & ~APR_INHERIT;
  +    if ((*new_file)->filedes <= 2) {
  +        (*new_file)->flags = old_file->flags | APR_INHERIT;
  +    }
  +    else {
  +        (*new_file)->flags = old_file->flags & ~APR_INHERIT;
  +    }

With this change we presume that fd 0..2 are specials that are
always inherited.  I warned in the commit log;

    This brings Unix into line with Win32's implementation of dup.  If folks
    feel we should *only* apply this code to which_dup==2 cases, that's fine
    with me; although close(1); dup(n) would generally create a new fd 1 on
    unix, that code isn't portable to Win32 and should be strongly discouraged.

Perhaps that dup2() discrepancy should be respected.

Finally, perhaps we revert to following the status of the dup2() flavored
cleanup.  However, this is somewhat troublesome in the following case;

apr_file_close(x);
apr_file_dup2(x, y);

where x has no cleanup whatsoever, because the apr_file_close(x) has
already caused that cleanup to be killed.

The other option is to query the APR_FILE_NOCLOSE and APR_INHERIT
flags of x to determine what cleanup (if any) aught to be registered for the
dup2(x,...).

Bill 


Mime
View raw message