Реализация сопрограмм в Java

Я бы взглянул на это: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html , это довольно интересно и должно стать хорошей отправной точкой. Но, конечно, мы используем Java, поэтому мы можем работать лучше (или, может быть, хуже, потому что нет макросов :))

Насколько я понимаю, с сопрограммами обычно есть производитель и потребитель сопрограммы (или, по крайней мере, это наиболее распространенный паттерн). Но семантически вы не хотите, чтобы производитель называл потребителя или наоборот, потому что это вносит асимметрию. Но, учитывая то, как работают языки на основе стека, нам нужно, чтобы кто-то выполнял вызов.

Итак, вот очень простая иерархия типов:

public interface CoroutineProducer<T>
{
    public T Produce();
    public boolean isDone();
}

public interface CoroutineConsumer<T>
{
    public void Consume(T t);
}

public class CoroutineManager
{
    public static Execute<T>(CoroutineProducer<T> prod, CoroutineConsumer<T> con)
    {
        while(!prod.IsDone()) // really simple
        {
            T d = prod.Produce();
            con.Consume(d);
        }
    }
}

Теперь, конечно, самая сложная часть - это реализация интерфейсов, в частности, трудно разбить вычисление на отдельные шаги. Для этого вам, вероятно, понадобится целый другой набор постоянных управляющих структур . Основная идея состоит в том, что мы хотим смоделировать нелокальную передачу управления (в конечном итоге это похоже на моделирование goto ).Мы в основном хотим отказаться от использования стека и pc (счетчик программ), сохраняя состояние наших текущих операций в куче, а не в стеке. Поэтому нам понадобится куча вспомогательных классов.

Например:

Предположим, что в идеальном мире вы хотели бы написать потребителя, который выглядел бы так (псевдокод):

boolean is_done;
int other_state;
while(!is_done)
{
    //read input
    //parse input
    //yield input to coroutine
    //update is_done and other_state;
}

нам нужно абстрагироваться от локальной переменной типа is_done и other_state , и нам нужно абстрагироваться от самого цикла while, потому что наша yield подобная операция не будет использовать стек. Итак, давайте создадим абстракцию цикла while и связанные классы:

enum WhileState {BREAK, CONTINUE, YIELD}
abstract class WhileLoop<T>
{
    private boolean is_done;
    public boolean isDone() { return is_done;}
    private T rval;
    public T getReturnValue() {return rval;} 
    protected void setReturnValue(T val)
    {
        rval = val;
    }


    public T loop()
    {
        while(true)
        {
            WhileState state = execute();
            if(state == WhileState.YIELD)
                return getReturnValue();
            else if(state == WhileState.BREAK)
                    {
                       is_done = true;
                return null;
                    }
        }
    }
    protected abstract WhileState execute();
}

Основной трюк заключается в том, чтобы переместить локальные переменные в переменные class и превратить блоки области видимости в классы, что дает нам возможность чтобы «повторно войти» в наш «цикл» после получения возвращаемого значения.

Теперь реализуем нашего производителя.

public class SampleProducer : CoroutineProducer<Object>
{
    private WhileLoop<Object> loop;//our control structures become state!!
    public SampleProducer()
    {
        loop = new WhileLoop()
        {
            private int other_state;//our local variables become state of the control structure
            protected WhileState execute() 
            {
                //this implements a single iteration of the loop
                if(is_done) return WhileState.BREAK;
                //read input
                //parse input
                Object calcluated_value = ...;
                //update is_done, figure out if we want to continue
                setReturnValue(calculated_value);
                return WhileState.YIELD;
            }
        };
    }
    public Object Produce()
    {
        Object val = loop.loop();
        return val;
    }
    public boolean isDone()
    {
        //we are done when the loop has exited
        return loop.isDone();
    }
}

Аналогичные трюки можно проделать и с другими базовыми структурами потока управления. В идеале вы должны создать библиотеку этих вспомогательных классов, а затем использовать их для реализации этих простых интерфейсов, которые в конечном итоге дадут вам семантику совместных подпрограмм. Я уверен, что все, что я здесь написал, можно значительно обобщить и расширить.