[OPEN-ILS-DEV] PATCH: osrfConfig.C (dropping stderr messages)
Bill Erickson
billserickson at gmail.com
Fri Jun 29 09:36:44 EDT 2007
On 6/28/07, Mike Rylander <mrylander at gmail.com> wrote:
>
> On 6/28/07, Scott McKellar <mck9 at swbell.net> wrote:
> >
> > --- Mike Rylander <mrylander at gmail.com> wrote:
> >
> > <snip -- about closing stdin, stdout, and stderr in daemonize(), etc>
> >
> > I did a little research and got another idea out of a book
> > (Linux Application Development, by Johnson and Troan).
> >
>
> [snip]
>
> That is a solid plan. If you're raising your hand then I'd love to
> see the patch. I'd also like to get Bill's input, since this is his
> code we're beating about, but daemonization needs to be fixed up. */me
> pokes Bill*
>
> >
> > I'm not sure what to do if the parent needs to keep a file descriptor
> > open while denying it to the child. The simplest thing to do would
> > be to close everything with fcloseall(), and then reopen anything
> > you need.
>
> Hmm... it's heavy-handed, but there's no reason not to do this based
> on the current code. It would certainly eliminate potential confusion
> arising from open file handles. Let's just make sure there's a
> comment next to the fcloseall that explains the caveats and the
> fclose-std* alternative.
I'm concerned about the fcloseall() approach. Currently, we fork the
applications and application worker processes before the top-level process
calls daemonize(). The app processes communicate via pipes to their worker
children (which is something I'd like to re-design, but I'll save that
discussion for later), which, if I'm reading the man page for fcloseall()
correctly, will be closed by that system call.
-bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070629/7c1ce442/attachment-0001.html
More information about the Open-ils-dev
mailing list