Ok, here's a classic challenge for those of us on the JVM: coroutines. In JRuby, the issue has been forced upon us by the inclusion of somewhat localized coroutines for external enumeration in Ruby 1.8.7 and general coroutines in the form of fibers in 1.9. The two cases are slightly different.
For external enumerating coroutines, we can have options that simulate coroutine state. For example, the Enumerator for a core Array class could know how to "next" through the array elements without using a coroutine to call "each" with a block. But for other cases that may have arbitrarily-complex iteration logic, we need a full-on coroutine to hop in and out of that logic. And for these cases we must spin up a thread to do the iteration. For fibers, the logic is almost always going to be arbitrarily complex, so they'll be a fiber in every case. We'll use pooling tricks to reduce the overhead of spinning up fibers, but we can't avoid using threads to implement them. Functionally, spinning up threads where needed and ping-ponging state back and forth is not a serious functional challenge. The challenge is in managing the *lifecycle* of those threads. The use of threads for simulating coroutines has a few immediate problems: 1. Threads are more expensive to spin up 2. Thread counts may be limited by the host platform 3. Threads root objects, for GC purposes 4. Threads will not GC until terminated The latter two issues have been keeping me up nights. I'm looking for suggestions. Because Threads can root objects, and because we may want a fiber or enumerator to GC before they've reached a terminal state (finished enumerating/fiber exits), two major complexities arrive. * The fiber/enum object can hold a hard reference to the thread, but must define a finalizer so that when they are ready for collection they can terminate the coroutine thread * The thread must have a hard reference to the fiber/enum object, so as not to interfere with it coming eligible for collection Both of these stem from the realization that an incomplete enumeration/fiber/generator can ultimately hold state forever, if the thread doing that enumeration can't be killed once it would be eligible for GC. If it were possible to create "unrooting" threads, or perhaps threads that only reference but do not root objects in their stacks, this all become much easier...but I don't think there's a way currently to create such threads, is there? Are there other ways to implement this I've missed? Of course I know about the approach Rife and Scala take for continuations in very localized conditions, but they can't work across aribitrary libraries that have not been similarly manipulated. I'm now getting more desperate to see coroutines added to *any* production-class JVM, even if I have to sign a waiver and pay a pound of flesh to get at it. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
