apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/file_io/unix filedup.c
Date Fri, 11 Jan 2002 10:18:51 GMT
> > dreid       02/01/11 01:04:51
> >
> >   Modified:    include  apr_file_io.h
> >                file_io/unix filedup.c
> >   Log:
> >   Add apr_file_dup2.
> >
> >   This has implications in that we now only do dup2 when we call
> >   apr_file_dup2 and this will potentially cause problems for code
> >   using apr_file_dup. The changes attempt to follow posix more closely.
> Well, more to the point, doesn't vary the behavior based on a (apr_t
> arg that folks might not initialize :)  In fact, I wondered why you didn't
> change the type to apr_file_t *dup2_file?

I didn't want to muck the code around more than I needed to and having the
same semantics for both seemed like a good idea.

> >   Will Rowe is going to tackle Win32 and OS/2 today.
> >   Changes to apache on the way.
> I'm afraid I'm out-of-time [hoped your patch would be in wed eve.]

I was in Houston :(  Got back this am and committed first thing (haven't
even gone to bed yet!!)

> Win32 is done, if you adopt the *dup2_file instead of **dup2_file, please
> fix win32's (*new_file)-> entries to new_file->.
> >   Issues: what should we do for dup2 when we have differing pools being
> >   used?
> Well, if the file exists, we should use the existing apr_file_t's pool,
> it dies when it goes out of scope.  Don't register a cleanup, it should
> done so already

Hmm, the question remains that if we have a file_t from pool a, but the file
being dup2'd is in pool b, should we "move" the file_t from pool a to b as
the lifetime of the file may be tied to pool b.  I'm not sure I know the
answer to that one which is why i didn't muck around with it.

> The old apr_file_dup should always use the *p for things like filename
> etc.  Win32's code was very broken these ways, before I just fixed it.



View raw message