On 25/06/2016 11:00 PM, rikki cattermole wrote:
... snip ...

What we want is to be able to explicitly say what the context is for a
functions code and declare no globals.

@noglobals
struct MyContext {

    @disable
    this(this);

    void func() {

    }
}

Function calls outside of the struct are ok for: @system, pure and
@noglobals.
Making the struct pure wouldn't work since there goes @safe and @system
calls.

MyContext.func would implicitly have @noglobals applied to it.

Now preferably we would have new hooks added so they could be in the
context. Specifically if they are there they are used instead of the
globals for e.g. GC. That way things like allocators could be used
instead. Given that the context should be heap/stack allocated and never
copied it would mean that once the fiber dies, all memory it uses is
deallocated or returned to the pool.

Now I did say about hooks, there are no ways to do that without having a
bunch of context pointers somewhere saying which function is currently
set to the hook. If done via a stack it would given history for
unsetting the current context allowing recursive.

The underlying fiber provider would have to inform the switch on e.g.
yield. But that isn't hard to do.

Looking back perhaps we can allow globals, but we'd need to instead have
a hook for when assigning to a global / passing to anything not pure
that is heap based. That would allow "moving" memory ownership from the
fiber to the process GC.


TLDR: I think we can do this with just a @noglobals attribute, but done
properly it looks like we need proper hooks in place which are a lot
harder.

I've thought about this further, the only hook function we don't currently have is related to global + TLS assignment for memory. We can get away with e.g. new overriding and ~ via the GC proxy (actually a fairly decent way to go about it).

Since this assignment hook is potentially quite expensive, it definitely should be only if used under whatever attribute we use.

Reply via email to