std.allocator needs your help

[Andrei Alexandrescu]

On 9/23/13 10:01 AM, deadalnix wrote:
> On Sunday, 22 September 2013 at 23:49:56 UTC, Andrei Alexandrescu wrote:
>> Hello,
>>
>
> First of all, awesome !
>
> Now the meeeeh part.
>
> I really think the it thing is not good. I don't think it is desirable
> or necessary. We should get rid of it.

The singleton allocator "it" is instrumental for supporting stateful and 
stateless allocators with ease. It took me a few iterations to get to 
that, and I'm very pleased with the results. I think it would be 
difficult to improve on it without making other parts more difficult.

> You can't deal with ubyte[] like that, that is incorrect in regard to -
> unimplemented - aliasing rules. Allocator should deal with void[] .

I think I'll do that.

> What you call safe really isn't. Allocate something on the GC, store a
> pointer on a custom allocated location, collect, enjoy the memory
> corruption.

I don't understand this. There are no pointers at this level, only 
untyped memory. The main chance of corruption is to access something 
after it's been freed.

> All operation are safe according to your proposal.

No, for most allocators freeing and reallocating are unsafe.

> Allocation can only be safe if the GRAND MASTER GC is aware of it.

I don't think so.

> You proposal allocate shared memory.

No. It allocates unshared memory off of a shared or unshared allocator. 
The memory just allocated is as of yet unshared for the simple reason 
that only one thread has as of yet access to it.

> This is common in C/C++ world as
> memory is shared by default, but shouldn't be in D. It is highly
> desirable to allocate with different methods for different type
> qualifier. How does your design adapt to that ?

The typed allocators will have distinct methods for shared and unshared 
allocation. Even at this level it's possible to design an allocator that 
allocates in different ways with a shared vs. an unshared allocator 
object (overload on shared). So far I've only designed non-shared 
allocators, or wrap those that are already shared (malloc and new).

> Finally, we got to decide how these basics block are used to form typed
> allocators, and interact with language constructs.

Sure. Again: I describe the Otto cycle and you discuss how to paint the 
road.


Andrei