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 Thu, 06 Mar 2003 01:14:12 GMT
At 04:24 PM 3/5/2003, Bjoern A. Zeeb wrote:
>On Wed, 5 Mar 2003, William A. Rowe, Jr. wrote:
>> At 01:54 PM 3/5/2003, Joe Orton wrote:
>> >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.)

You are welcome.

>Perhaps then also have s.th. like an "alias" apr_pipe_(un)set_inherit to
>apr_file_(un)set_inherit ? It perhaps would make some lines of code
>more clear...

No - because the API functions are not apr_pipe_foo.

Pipes use the apr_file_ api, period.  Since on all platforms they take
an apr_file_t, it doesn't matter anyways.  If there is any distinction,
that will happen in the _create and _cleanup code as appropriate.

(And that's inherit_[un]set, not visa versa :-)

>< may be ignored >
>Just 'cause I currently saw this: why is it named apr_file_cleanup on
>1/2OS aaeh OS/2 and apr_unix_file_cleanup ? And it seems to be only
>named file_cleanup for win32.

Because you *shouldn't* know the internals of those cleanups.  It's entirely
irrelevant internals of APR.

>Functions are also named apr_file_open or apr_file_pipe_create for
>unix. So ich someone touches this perhaps we can also do some cleanup
>for thos cleanup_fns ? Ok, I can hear you till here go *waaah* ;-))))
>If I am right with my limited apache/apr experience this functions
>should be/"are" hidden from users so it should not be real problem ?

Exactly - it should all be transparent to them.

No user should be adding/removing the cleanups - it is up to the
accessors such as apr_file_inherit_[un]set to do such things.


View raw message