Re: debugging guile runtime

[rixed]

> > (BTW, if anyone knows the rational behind this, I would be glad to
> > know).
> 
> When typing ???foo 2< baz 5> bar??? in a shell, the shell first forks, the
> opens/dups 2 and 5, and finally execs ???foo???, which gets to see 2 and 5
> as open FDs.

Yes, the shell can open/dup the file additional files you explicitly
ask for, but the point is that it will nonetheless closes the file
descriptors it is using itself.  For instance my shell is using these
files :

$ ls -l /proc/$(pidof zsh)/fd
lrwx------ 1 rixed rixed 64 Aug 31 09:25 0 -> /dev/tty1
lrwx------ 1 rixed rixed 64 Aug 31 09:25 1 -> /dev/tty1
lrwx------ 1 rixed rixed 64 Aug 31 09:25 10 -> /dev/tty1
lr-x------ 1 rixed rixed 64 Aug 31 09:25 11 -> /debian/home/rixed/.zshenv
lr-x------ 1 rixed rixed 64 Aug 31 09:25 12 -> /debian/home/rixed/.profile
lrwx------ 1 rixed rixed 64 Aug 31 09:25 2 -> /dev/tty1

but the children it execs do not come with files 10, 11 and 12 opened.
So this is my understanding that when the shell exec a command it closes
all but the required files between fork and exec, while popen do not.

This is getting off-topic, though.

> > Except that, as previously discussed in another thread, there is no easy
> > way to do that between the fork and the exec (since I don't want to
> > actually close these files in the main program that starts the pipe).
> 
> Hmm right.  We???d need to insert a hook in ???open-pipe??? so that, when this
> behavior is wanted, one can actually close those FDs.

If I'm the only one concerned then I can (and actually already did)
handle the issue using the close-on-exec flag (as was suggested to me on
this list when I raised the problem initially).

I'm much more interested in working to solve the FD_SETSIZE limit and/or
the ports thread safety issue. :-)