I'm not sure, but I'm going to hazard a guess.
I do know that if you open a filehandle to some device, and then you execute another program (via system, exec, whatever), the filehandle remains open and the new process can use it. This is what allows us to set up pipes so that stdin and stdout of a subprocess are regular files to the parent, etc.
However, I'm not so sure if that holds true for dir handles. Looking at the opendir (3) manpage, there is a "file descriptor" associated here, so it may be true here, too.
What does this have to do with exit? Very little. In fact, nothing. But if you have the cleanup routine, you could do something like this:
sub system_no_filehandles {
my $pid = fork();
if ($pid) {
waitpid($pid, 0);
return $?
}
cleanup_all_filehandles();
cleanup_all_dirhandles();
exec(@_);
}
The subprocess will not have any of the files or directories opened, thus the file descriptor table will be as clean as possible for that child. I've had cases where this has been important - I've had to write wrappers (in C at the time) where I'd just loop through all file descriptors from 3 to 255, closing each one, and then exec'ing the next process which needs way too many files opened at a time, but was failing for lack of descriptors. So this technique can be quite useful, but it requires discipline up front to manage the list - it's not something that's easy to add later. | [reply]
[d/l] |
| [reply] |
Only because I didn't want to perform a close unnecessarily. Also because I was trying to learn and possibly implement some good practise by ensuring that anything opened was noted as being opened, and anything noted as being opened was closed.
It seems a bit amiss that there's no simple way (mentioned so far) to tell if the directory handle is actually open or not.
Cheers for your help! Most appreciated. | [reply] |