"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message news:op.vipr20xfeav...@localhost.localdomain... > On Tue, 07 Sep 2010 16:51:48 -0400, Nick Sabalausky <a...@a.a> wrote: > >> >> Ah cool, looking forward to it. I was just about ready to launch into a >> bunch of std.process improvements myself ;) In the meantime, it seems >> that >> File has an undocumented constructor that takes a file handle instead of >> a >> filename, so that should work for me. > > Beware, it takes a file *descriptor*, which is different from a *HANDLE* > on windows. In writing the updated std.process I had to write D code that > mimics the internals of DMC's runtime in order to translate between file > descriptors and handles, not a pretty sight... >
I'm just feeding it the values I get from CreatePipe: http://msdn.microsoft.com/en-us/library/aa365152(VS.85).aspx Seems to be working fine, though... > The updates are being held back right now by bug 3979. > >> BTW, do any of the upcoming std.process changes do anything to help work >> around Windows's exec being broken? By that I mean, exec is supposed to >> *reuse* the current process when launching the new one, but on Windows >> (and >> I *don't* believe this is D-specific) it creates a *new* process and >> kills >> the old one, which fucks up anything that waits on the original process >> to >> finish (such as the command-line). spawn(OVERLAY) has the same problem. > > Windows' exec is a hack. std.process will not use it, instead, we'll use > CreateProcess directly. > Yea, I've come to the conclusion, too, that exec and spawn(OVERLAY) are worthless on Windows. I was going to create and submit a patch that avoids them and uses system instead (which *does* maintain the current pid) and then exits. But if someone's already been doing this, and using CreateProcess directly, then all the better :) > FWIW, we are not going to support fork or exec individually in > std.process. We will only support creating a new process via fork+exec or > CreateProcess. This is the common functionality among OSes. > > If you want fork or exec individually, you have to use them on posix > systems only, and call them directly. > Sounds good.