The new std.process is ready for review

[Lars T. Kyllingstad]

On Saturday, 9 March 2013 at 18:54:31 UTC, Steven Schveighoffer 
wrote:
> On Sat, 09 Mar 2013 13:44:44 -0500, Lars T. Kyllingstad 
> <public at kyllingen.net> wrote:
>
>> On Saturday, 9 March 2013 at 18:35:25 UTC, Steven 
>> Schveighoffer wrote:
>
>>> How do you loop over all open ones?  Just curious :)
>>
>> You don't.  That is why I said solution (3) sucks too. :)  You 
>> have to loop over all possible non-std file descriptors, i.e. 
>> from 3 to the maximum number of open files.  (On my Ubuntu 
>> installation, this is by default 1024, but may be as much as 
>> 4096.  I don't know about other *NIXes)
>>
>> Here is how to do it:
>>
>> import core.sys.posix.unistd, core.sys.posix.sys.resource;
>> rlimit r;
>> getrlimit(RLIMIT_NOFILE, &r);
>> for (int i = 0; i < r.rlim_cur; ++i)
>>     close(i);
>
> Hm... don't close 0, 1, 2 :)
>
> On Linux at least, you could use /proc/self/fd  I suppose it's 
> faster just to loop though.
>
> How long does it take when you close non-open descriptors?  We 
> don't want to hamper performance too much.

On my computer, with 1024 (minus 3 ;))possible file descriptors, 
it roughly doubles the time spent inside spawnProcess() up to, 
but not including, the excecve() call.  (About 0.1 microsecond 
per file descriptor.)  Considering that execve() probebly dwarfs 
that number, I think we're in good shape.

Of course, we have a problem if some other platform allows 
ulong.max open files...

> I wonder if select on all possible file descriptors in the 
> fd_err parameter would give you a clue as to which were invalid.

My guess is that select() uses more or less the same mechanism as 
close() for checking FD validity, and thus would gain us nothing.

Lars