> > 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 **result) > 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, since > it dies when it goes out of scope. Don't register a cleanup, it should have > 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 dup, > etc. Win32's code was very broken these ways, before I just fixed it. Excellent. david
