Vote for std.process

Manu turkeyman at gmail.com
Fri Apr 12 01:14:15 PDT 2013


On 12 April 2013 17:35, Steven Schveighoffer <schveiguy at yahoo.com> wrote:

> On Fri, 12 Apr 2013 03:04:08 -0400, Manu <turkeyman at gmail.com> wrote:
>
 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"?
>

Yes.


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


I'd use string[].


 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.


A trivial ... mixin template (?) could wrap it up, I don't see it
particularly less convenient than calling toStringz().
Perhaps there are other tools missing from phobos if this is somehow hard...


 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.
>

I've never seem the compiler apply that optimisation, although I often wish
it would.
I saw an appender appear a few pages below, that would be an improvement
here too I guess.


 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.


Writing cross-platform code is my life.
They are trivial conversions. It could be done on the stack easily.
Granted, ideally the compiler could theoretically perform some of those
improvements, but it doesn't, and probably depends on other changes to be
able to do so anyway.
For instance, the compiler couldn't confidently lower the allocations to
the stack unless 'scope' arguments worked, so it knew it wouldn't escape
the OS call it was being handed to.


 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.


But it would be trivial to use the stack in these cases. It doesn't matter
if it adds a few lines under the hood.

I'm really just trying to make the point that it should ALWAYS be a key
consideration, and people should make it habit to think about/criticise
these things when accepting code into phobos.
This is the standard library, it will be used in more D code than any other
library ever. Why skimp here?


 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.


In this case you certainly can, it would be fairly trivial to do.


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

What pain? Are you saying a stack variable is somehow hard?
If that's the case, then there's clearly some other fundamental tools
missing from phobos.


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.
>

No, it's to save (ideally) _all_ programmers the effort of rewriting this
module themselves.
This is exactly the sort of thing I waste loads of my life doing, rewriting
wheels because the author was a PC programmer, and simply didn't give a
shit.
What a waste of life >_<

I re-iterate, maybe my points aren't of critical importance in relation to
std.process specifically, I'm trying to raise some general issues with
phobos submissions (that shouldn't exclude std.process either).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130412/339f4099/attachment-0001.html>


More information about the Digitalmars-d mailing list