I tend to agree with Jon. On Windows, this is required behavior, and we should enforce it. On Unix, the OS is going to open fd's 0-2 automatically. In order for them to no longer be opened when the program is run, the programmer must have done something to close them.
On Windows, the function should exist and it should open the fds. On Unix, the function should exist, but it should be a no-op. Ryan ---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 14, 2002 2:44 PM > To: Sander Striker > Cc: Sascha Schumann; Jon Travis; dev@apr.apache.org > Subject: RE: Unix missing fd 0..2, Win32 service missing stdin/out/err > handles > > At 04:39 PM 4/14/2002, Sander Striker wrote: > > > From: Sascha Schumann [mailto:[EMAIL PROTECTED] > > > Sent: 14 April 2002 22:46 > > > > > do { > > > fd = open("/dev/null", O_RDWR); > > > } while (fd < 3); > > > close(fd); > > > >And this is what most daemons (mostly) do. We could create a > >convenience function for this. I don't think it should be default > >apr behaviour though. APR is a library. Libraries shouldn't > >take options away from users. > > Notice -where- I suggested we put this code. > > apr_initialize() performs library initialization. It doesn't care what > program > is using the APR features. > > apr_app_initialize is -required- on win32 to compensate for Unicode, > windows services, and the console 'signals' API. > > An application -entirely- APR-centric Will use apr_app_initialize to > compensate for whatever platform it was built-for/running-on. If this is > platform compensation, Sascha and I are only suggesting that a typical > app (daemon or not) will -prefer- this behavior at -invocation-. > > If that app then closes fd 0..2, we don't care. I'm absolutely -not- > suggesting that we would ever want to test that apr_file_open() doesn't > return an fd 0..2. Only for startup of an app that we don't know -who- > has invoked us, or what a broken daemon-manager has overlooked. > > Bill
