Vote for std.process

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Apr 12 04:38:07 PDT 2013


12-Apr-2013 11:04, Manu пишет:
> On 12 April 2013 14:46, Jesse Phillips <Jessekphillips+d at gmail.com
> <mailto: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:
>
> 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.
>
> 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.
>

Most of this is unsolvable until there is a STANDARD 
interface/policy/hooks for allocators in Phobos. All work to get around 
the cases like that at the moment is just a waste of time or specific 
hacks for particular bottlenecks.

I did a fair amount of these in std.regex to make matching GC-free and 
almost heap-free - it preallocates on the first call. It's an example of 
a necessary hack and it's not pretty. More then that I'm sure I'd have 
to re-write the whole memory allocation code once we (finally!) have he 
standard way to do it.

TL;DR - until using allocators is easy and straight-forward (and 
standard) there would be no end of GC-only hegeomny 'cause it's 
easier/simpler. Not much to discuss ;)

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

Horrible...
But let's focus on the API parts. The internals could be fixed with a 
pull request or two. Freaking out because of a GC happy code doesn't 
help those waiting for *any* sane process management module in std.


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list