On 13 April 2013 00:01, Regan Heath <regan@netmail.co.nz> wrote:
On Fri, 12 Apr 2013 14:25:22 +0100, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

12-Apr-2013 17:20, Dicebot пишет:
On Friday, 12 April 2013 at 13:09:19 UTC, Lars T. Kyllingstad wrote:
On Friday, 12 April 2013 at 13:00:36 UTC, Robert wrote:
I would suggest, instead of writing your own std.process, that you
simply provide a pull request to the now to be approved one, this way
you can prove your point that it is easy by already improving a part of
the standard library.

Actually, Manu (or anyone) could do this for *any* part of Phobos.
And considering that std.process is probably the module that would
benefit the least from it, maybe he should start somewhere else?
std.string, perhaps, or std.algorithm?

Or probably druntime. This rise again and again - until standard global
allocators are not here it is all a premature and useless optimization.
It makes no sense to try to workaround a fundamental issue. That will be
a lot of effort for no real gain.

Allocators are a blocker for almost any memory-related issue in both
druntime and phobos.

Same here - trying to get out of your way to avoid GC right now is both painful and useless in the long run. More then that it's limited as you can't have the default allocation scheme that fits all nor use some scheme that would require change of API (so that later it's broken again once allocators come).

My impression is that there is some low hanging fruit here.  My impression (pls correct me if I'm wrong) is that Manu is not trying to avoid the GC, but to avoid allocations (and presumably collections) at the wrong moment in time.

So...

If the GC were to have a hook function for allocation and for free, and if when these were in use it would not itself trigger collection.

Then...

Manu could supply hook functions, use the alloc function to supply pre-allocated memory, and trigger collection as/when convenient.

Believe it or not, I'm not actually a fan of over-complexity. And I'm focusing here on totally unnecessary allocations.
Isn't using the stack where applicable just a whole low easier? That's what it's there for.

There are of course plenty of functions that do allocate by design, and in many cases, allocators would assist with those. But I'm not arguing for that right now, since allocators still seem to be a way off.

For collection itself some upper bound time would also be desireable.

Absolutely. Is it possible for collection to run like a coroutine? Can it run a fragmented collection process, each time picking up where it left off?

These ideas are nowhere near as complex as a full blown allocator proposal/idea.