Vote for std.process

[Steven Schveighoffer]

On Fri, 12 Apr 2013 03:04:08 -0400, Manu <turkeyman at gmail.com> wrote:

> On 12 April 2013 14:46, Jesse Phillips <Jessekphillips+d at gmail.com>  
> wrote:
>
>> It is that time, If you would like to see the proposed std.process  
>> include
>> into Phobos please vote yes. If one condition must be met specify under
>> what condition, otherwise vote no.
>>
>
> I didn't think I had much of an opinion on std.process, but I just gave  
> it
> a quick once over and noticed, relating to our recent discussions about
> flagrant GC usage throughout phobos, that this is riddled with the exact
> sorts of issues I've been talking about:

It's spawning a new process.  What is the issue with allocating a bit of  
memory?  The spawning of the process performance is going to dwarf that of  
any memory allocations.

> string[string] is used in the main API to receive environment variables;
> perhaps kinda convenient, but it's impossible to supply environment
> variables with loads of allocations.

I think you meant "without"?

What would be your suggestion?  string[string] is the built-in map type.   
How do you pass an environment map without having some allocations?

> toStringz is used liberally; alternatively, alloca() could allocate the
> c-string's on the stack and zero terminate them there, passing a pointer  
> to
> the stack string to the OS functions.

This would be a lot of effort for pretty much zero gain for the majority  
of cases.

> String concatenation is rampant! Look at this code to parse the env
> variables (which are already an AA):
>
>     foreach (var, val; childEnv)
>         envz[pos++] = (var~'='~val~'\0').ptr;

This could be improved.  It could also be optimized into a single  
allocation automatically by the compiler (it might already be).  The API  
would not be affected by this improvement, though.

> And many many more of the same...
>
> This is a lib that spawns a process, I can't imagine why this library
> should need to allocate a single byte, but it allocates wildly just to
> perform a trivial pass-through to the OS.

It is not a trivial pass-through.  Different OSes require different  
parameter types.  Look at the difference between the windows and posix  
implementations.  We are writing a cross-platform library, so whatever we  
pick will have to be converted on at least one OS.

> This module is no exception either, basically all of phobos is like this,
> and I'd like to see careful consideration made to these details in the
> future.

I too like to avoid memory allocations.  But the level to which you  
require is too stringent.  Not even Tango, which made low heap-allocations  
a priority, avoided allocations in it's process library.

> I've said before, I sadly have to avoid phobos like the plague. Some
> modules (like this one) that provide fundamental functionality - not just
> helper functions - can't be avoided. Requirements for those should be  
> extra
> strict in my opinion.

We cannot cater to all developers.  To put all developers through a lot of  
pain in order to attract the fringe ones is not a practical goal.

I think the convenience of std.process is what it is there for.  For the  
highest performance, you are able to call the OS functions directly.

-Steve