apr-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: [PATCH] inheriting pipes
Date Wed, 05 Mar 2003 21:41:45 GMT
At 01:54 PM 3/5/2003, Joe Orton wrote:
>> But why not just register apr_unix_file_cleanup for cleanup like in
>
>Indeed, I wonder it was implement this way too.  I think the change you
>suggest is a little more intrusive than mine, as currently some callers
>are compensating for the fact that no child_cleanup is registered.

I agree we must register a cleanup so that we don't have to jump through
hoops later.  APR app developers should be able to trust that there is
already a cleanup registered for such objects they create.

>I also wonder why the code goes to these lengths when on Unix setting
>the CLOEXEC flag would probably suffice.

We should do *either*;  if CLOEXEC is supported and can be toggled
per our API (_set/_unset) then that can be the preferred method, to protect
ourselves from non-apr callers of exec().  (This goes for files, too.)


>> --- httpd-2.0.44/srclib/apr/file_io/unix/pipe.c.orig    Sun Mar  2 00:54:10
>> 2003
>> +++ httpd-2.0.44/srclib/apr/file_io/unix/pipe.c Sun Mar  2 00:54:36 2003
>> @@ -225,9 +225,9 @@
>>  #endif
>> 
>>      apr_pool_cleanup_register((*in)->pool, (void *)(*in), apr_unix_file_cleanup,
>> -                         apr_pool_cleanup_null);
>> +                         apr_unix_file_cleanup);
>>      apr_pool_cleanup_register((*out)->pool, (void *)(*out), apr_unix_file_cleanup,
>> -                         apr_pool_cleanup_null);
>> +                         apr_unix_file_cleanup);
>>      return APR_SUCCESS;
>>  }
>> 
>> would this not be more to the point of getting the descriptors closed on exec.
>> 
>> Greetings
>> Christian
>> 
>> -- 
>> CK Software GmbH
>> Christian Kratzer,         Schwarzwaldstr. 31, 71131 Jettingen
>> Email: ck@cksoft.de
>> Phone: +49 7452 889-135    Open Software Solutions, Network Security
>> Fax:   +49 7452 889-136    FreeBSD spoken here!
>> 



Mime
View raw message