12-Apr-2013 11:04, Manu пишет:
On 12 April 2013 14:46, Jesse Phillips <[email protected]
<mailto:[email protected]>> 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

Reply via email to