D wrappers around C wrappers, was: Why are the exec* functions deprecated in std.process?

[Marco Leise]

Am Tue, 29 Oct 2013 16:42:08 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 10/29/13 3:07 PM, Lars T. Kyllingstad wrote:
> ...
> > I suspect that these functions were only included in Windows to satisfy
> > POSIX requirements (which they fail to do).
> >
> > We should discourage their use on Windows, and one way to do this is to
> > *not* have a nice cross-platform interface to them in Phobos.
> 
> Well argued. I'm okay with moving this to a posix-specific module and 
> mentioning it in std.process.
> 
> Andrei

That was an interesting discussion. With every new post I was
switching sides.

The fact that on Windows it is just emulated with
CreateProcess reminded me how Phobos still uses "emulation"
layers for I/O, namely C files in one or two places.
If at some point Phobos used OS functionality exclusively
instead of D wrappers around C wrappers, we could fix the
O_CLOEXEC issue.

By default Posix keeps file descriptors from the original
process open after an exec(), whereas Windows asks you for
'inheritance' at file creation time and when you spawn a
subprocess. We had a discussion about it when std.process was
ready for review, so I'll cut it short.

C doesn't offer a standard mode flag for file inheritance, so
every C library does it differently. If Phobos is to offer a
portable file handling, it needs to have platform specific
code and default to not inheriting file descriptors.

I think it was Steven, who argued that with everyone using
std.process, no open file handles would ever slip through an
exec() call (since std.process closes them all manually), but
Andrei's almost use of bare bones C exec() shows once again
that the issue is not mitigated.
I had a patch for Phobos in the pipe, that ensures, O_CLOEXEC
is set everywhere a file is opened (e.g. file streams), but I
had to stop at std.stdio, where the C API is exposed in the
form of mode flag strings - which already offer the
non-portable way of setting O_CLOEXEC through different flags
for each C library. So next you would see me argue for a
replacement of zero-terminated mode strings with something
more D-ish and at that point we are in a full blown debate
about a std.stdio rewrite...

So for now just remember to open all files with O_CLOEXEC
(available as the "e" mode flag for glibc) on Linux unless
you-know-what-you-are-doing™.

-- 
Marco