Wouldn't Python style generators be enough for most use cases? It would require a "yield next" keyword ("yield" is already taken) that would instruct the compiler to transform the calling function into a state machine. On the other hand, it would make users happy that they don't need to explicitly maintain their state and also implementers happy that they don't need to use fibers/threads.

Tomas

-----Original Message-----
From: Charles Oliver Nutter [mailto:headius / headius.com] 
Sent: Friday, September 25, 2009 5:54 PM
To: ruby-core / ruby-lang.org
Subject: [ruby-core:25779] Re: A challenge: Enumerator#next in JRuby

On Fri, Sep 25, 2009 at 7:35 PM, Nobuyoshi Nakada <nobu / ruby-lang.org> wrote:
> At Sat, 26 Sep 2009 05:18:02 +0900,
> Charles Oliver Nutter wrote in [ruby-core:25769]:
>> Functionally, this works just fine, other than the cost of us 
>> spinning up a thread. But there's a larger problem: an 
>> Enumerator-created thread has a full lifecycle apart from the 
>> caller's thread. As a result the enumerator thread can root objects 
>> (preventing them from being GCed), including the Enumerator itself.
>
> Why does the enumerator thread make the Enumerator marked?

Any objects referenced by the enumerator thread will be strongly referenced, as you'd expect. The current implementation lives within the Enumerator that started it, causing that Enumerator instance to be referenced as well, which keeps it from being collected, which keeps the thread from being killed, etc. It's mostly an implementation issue to isolate the thread from the enumerator. I think we can do it with a combination of weak references and finalizers, but it doesn't address the primary problem: it's spinning up threads for every enumerator you want to "next" over.

- Charlie