История изменений

Ну во-первых вики - не достоверный источник.

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

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

В-четвертых, и если в юнити не корутины, то в Lua тогда что? Я не вижу разниц между примерами Unity/Lua в самом первом своем сообщении/вопросе кроме того, что в Lua корутины нужно руками запускать, а в Unity их запускает шедулер (тот самый run loop, который так же запускает Update() каждый фрейм), почему я и спросил fiber’ы они или нет. Но сейчас подумав немного прихожу к выводу, что таки нет, так как шедулер выбирать нельзя, да и не до конца это шедулер, а main loop.

В-пятых, «дяденька я не сварщик, а только каску нашел» (с) анекдот. Я сам хочу разобраться. В том, что ты говорил есть как минимум несколько вещей, которые не соответствуют тому, что я читал/смотрел. Например, что для fiber’ов (lightweight threads) нужны мутексы и прочие способы синхронизации, тогда как они не нужны.

В-шестых, я сам не до конца понимаю, что делает корутину волокном (fiber) кроме шедулера. Явно возможность делать так, что если две корутины обе ждут третью - то все работает как-то с этим связано. А это в свою очередь явно связано с рекурсивностью стэка. Или под стэком ты имеешь ввиду только стэк вызова функций, а не переменные и их состояние? Ну так это с точки зрения ассемблера не правильно, в стэке лежат как переменные так и адреса возврата из функций и их параметры. Так или иначе я хочу разобраться, а не флеймить. Я прочел/посмотрел вот это:

И так до конца не понимаю разницу между реализацией корутин vs волокон. Конкретно, не понимаю, что нужно для того, чтобы разруливать ситуацию где от одной корутины зависят множество других и появляется граф - что необходимо, чтобы это работало с любым типом шедулера (обычный цикл, шедулер с приоритетом, шедулер, который "join"ит родительские корутины, когда закончены вызванные ними, шедулер, который "join"ит все корутины только когда ни одной не осталось и т.д.) и не было deadlock’ов.

А ты мне вики в нос тычешь.

Может вот это что-то прояснит:

https://blog.panicsoftware.com/coroutines-introduction/

(не прочел пока). Но это про корутины в C++, а они там убогие (раньше вообще назывались resumable functions и были реализованы первыми Microsoft’ом). Т.е. с boost::fibers это мало связано.

Ну во-первых вики - не достоверный источник.

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

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

В-четвертых, и если в юнити не корутины, то в Lua тогда что? Я не вижу разниц между примерами Unity/Lua в самом первом своем сообщении/вопросе кроме того, что в Lua корутины нужно руками запускать, а в Unity их запускает шедулер (тот самый run loop, который так же запускает Update() каждый фрейм), почему я и спросил fiber’ы они или нет. Но сейчас подумав немного прихожу к выводу, что таки нет, так как шедулер выбирать нельзя, да и не до конца это шедулер, а main loop.

В-пятых, «дяденька я не сварщик, а только каску нашел» (с) анекдот. Я сам хочу разобраться. В том, что ты говорил есть как минимум несколько вещей, которые не соответствуют тому, что я читал/смотрел. Например, что для fiber’ов (lightweight threads) нужны мутексы и прочие способы синхронизации, тогда как они не нужны.

В-шестых, я сам не до конца понимаю, что делает корутину волокном (fiber) кроме шедулера. Явно возможность делать так, что если две корутины обе ждут третью - то все работает как-то с этим связано. А это в свою очередь явно связано с рекурсивностью стэка. Или под стэком ты имеешь ввиду только стэк вызова функций, а не переменные и их состояние? Ну так это с точки зрения ассемблера не правильно, в стэке лежат как переменные так и адреса возврата из функций и их параметры. Так или иначе я хочу разобраться, а не флеймить. Я прочел/посмотрел вот это:

И так до конца не понимаю разницу между реализацией корутин vs волокон. Конкретно, не понимаю, что нужно для того, чтобы разруливать ситуацию где от одной корутины зависят множество других и появляется граф - что необходимо, чтобы это работало с любым типом шедулера (обычный цикл, шедулер с приоритетом, шедулер, который "join"ит родительские корутины, когда закончены вызванные ними, шедулер, который "join"ит все корутины только когда ни одной не осталось и т.д.)

А ты мне вики в нос тычешь.

Может вот это что-то прояснит:

https://blog.panicsoftware.com/coroutines-introduction/

(не прочел пока). Но это про корутины в C++, а они там убогие (раньше вообще назывались resumable functions и были реализованы первыми Microsoft’ом). Т.е. с boost::fibers это мало связано.

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

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

В-третьих, и если в юнити не корутины, то в Lua тогда что? Я не вижу разниц между примерами Unity/Lua в самом первом своем сообщении/вопросе кроме того, что в Lua корутины нужно руками запускать, а в Unity их запускает шедулер (тот самый run loop, который так же запускает Update() каждый фрейм), почему я и спросил fiber’ы они или нет. Но сейчас подумав немного прихожу к выводу, что таки нет, так как шедулер выбирать нельзя, да и не до конца это шедулер, а main loop.

В-четвертых, «дяденька я не сварщик, а только каску нашел» (с) анекдот. Я сам хочу разобраться. В том, что ты говорил есть как минимум несколько вещей, которые не соответствуют тому, что я читал/смотрел. Например, что для fiber’ов (lightweight threads) нужны мутексы и прочие способы синхронизации, тогда как они не нужны.

В-пятых, я сам не до конца понимаю, что делает корутину волокном (fiber) кроме шедулера. Явно возможность делать так, что если две корутины обе ждут третью - то все работает как-то с этим связано. А это в свою очередь явно связано с рекурсивностью стэка. Или под стэком ты имеешь ввиду только стэк вызова функций, а не переменные и их состояние? Ну так это с точки зрения ассемблера не правильно, в стэке лежат как переменные так и адреса возврата из функций и их параметры. Так или иначе я хочу разобраться, а не флеймить. Я прочел/посмотрел вот это:

И так до конца не понимаю разницу между реализацией корутин vs волокон. Конкретно, не понимаю, что нужно для того, чтобы разруливать ситуацию где от одной корутины зависят множество других и появляется граф - что необходимо, чтобы это работало с любым типом шедулера (обычный цикл, шедулер с приоритетом, шедулер, который "join"ит родительские корутины, когда закончены вызванные ними, шедулер, который "join"ит все корутины только когда ни одной не осталось и т.д.)

А ты мне вики тычешь.

Может вот это что-то прояснит:

https://blog.panicsoftware.com/coroutines-introduction/

(не прочел пока). Но это про корутины в C++, а они там убогие (раньше вообще назывались resumable functions и были реализованы первыми Microsoft’ом). Т.е. с boost::fibers это мало связано.