How to close all files between fork and exec?

[Donn Cave]

Quoth aahz at panix.com (Aahz Maruch):
| In article <yv2lms8lyre.fsf at lionsp093.lion-ag.de>,
| Harald Kirsch  <kirschh at lionbioscience.com> wrote:
|> aahz at panix.com (Aahz Maruch) writes:
|> >
|> > from fork import open
|>  
|> Hmm, this is becoming somehow interesting because I have got no idea
|> why you think this relates in any way to my question. Either you try
|> to tease me or we have a communication problem. But I think I should
|> stay calm and try to start all over:
|> 
|> Suppose you have the assignment to write a module for me which, for
|> whatever reasons, has to fork/exec certain subprocesses. I want to use
|> your module as a service in my software. But my software will have a
|> whole bunch of files open when it calls your module. How did your
|> module keep track of all these files so that it is able to close them
|> all before execing. --- If you now say that your module cannot do that
|> and that it would be the obligation of my software to close unneded
|> files before calling your module, I at least start to understand your
|> arguments. However I maintain the opinion that this would be nonsense.

| To expand on my terse comment, "from fork import open" replaces the
| builtin function open() with the function from the fork module.  This
| function is a thin wrapper around the builtin open() that tracks all
| files that have ever been opened.  You can't write a wrapper for close()
| unless you also design a UserFile class that you return from open; it's
| not that useful, anyway, because a standard Python idiom is to let files
| fall out of scope and let them close themselves (which unfortunately
| won't happen in programs that use the fork module because the fork module
| will retain a reference; it's a trade-off).
|
| When you call the actual fork/exec function, it just checks to see which
| of the stored file handles are still open and then closes them.

Is this fork module hypothetical?

I think I agree with the original poster that it will be fundamentally
impractical to account for open files.  There are many operations that
open a file descriptor - besides builtin open(), of course we have
posix.open, posix.dup and dup2, socket.socket and I imagine plenty
more obscure functions, that return an open file descriptor or object 
clearly built around one.  Then there must be C libraries, e.g., maybe
a graphic interface toolkit that supports X11.  And even if you could
somehow account for all that, if the object is really to close every
last descriptor, what about the ones inherited by Python?

I am thankful for enlightenment about the sysconf() function.  Someone
may have supplied more details in this thread, but if so I didn't notice
it, so here goes.  posix.sysconf is available starting in Python 2.0.

   >>> import posix
   >>> posix.sysconf('SC_OPEN_MAX')
   1064
   >>>

	Donn Cave, donn at u.washington.edu