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: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
Date Sun, 14 Apr 2002 21:44:28 GMT
At 04:39 PM 4/14/2002, Sander Striker wrote:
> > From: Sascha Schumann [mailto:sascha@schumann.cx]
> > 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


Mime
View raw message