Generators in D

Piotr Szturmaj bncrbme at jadamspam.pl
Thu May 19 04:06:52 PDT 2011


Sean Kelly wrote:
> On May 18, 2011, at 5:07 PM, Piotr Szturmaj wrote:
>
>> Sean Kelly wrote:
>>>
>>> On May 18, 2011, at 8:00 AM, Piotr Szturmaj wrote:
>>>
>>>> Sean Kelly wrote:
>>>>> On May 17, 2011, at 2:37 PM, Piotr Szturmaj wrote:
>>>>>>
>>>>>> But couldn't Fiber's stack be scanned for references to itself and readjusted?
>>>>>
>>>>> Without type information, there's no way to be sure that something is actually a reference, so corruption could occur.
>>>>
>>>> Then, how GC scan Fiber's stack for references? I thought some portion of GC code could be used for this.
>>>
>>> The GC is conservative.  If it encounters a value that matches the address of GCed memory, it won't collect the memory.
>>
>> Ok. Maybe a requirement that cloneable fiber's function must be marked as @safe would work, as @safe functions can't take the address of a local variable or function parameter. Also asm and pointer arithmetic are prohibited. This way Fiber's stack can't have references to itself.
>>
>> That should be enough to implement ForwardRange's save() for generators. Or still, I'm missing something I don't know yet :)
>
> Referenced classes would still be shared between fibers.  I don't know if that would be an issue or not.

For in-process cloning that should not be an issue. Generator coders 
should be aware of cloning behaviour.


More information about the Digitalmars-d mailing list