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

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.

Например в том же Rust будет куча приседаний по вопросам:

1. Какой планировщик? Например далее пускай Tokio (еще есть runtime-native)

2. Хорошо ли ты подумал, отдать задачу на пул потоков или оставить в главном loop вместе с IO?

3. Не применил ли ты внутри Tokio обычный Mutex, вместо правильного mutex, совместимого с неблокирующим кодом.

4. Если создать цепочку вычислений, то на каком пуле конец цепочки будет выполнен? А если я попытаюсь результат двух future объединить и обработать, а один запущен на Tokio, а другой на пуле потоков? В той же Scala каждый сегмент цепочки получал на вход свой executor, как укажешь так и будет (хотя там никто и не ставил задачу делать zero-cost)

Там сейчас целая рабочая группа мозги ломает как улучшить эргономику. Я думаю у Perl 6 просто никто не дает таких гарантий по overhead как там, все чуть проще, но work stealing все равно неплохо бы иметь

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.

Например в том же Rust будет куча приседаний по вопросам:

1. Какой планировщик? Например далее пускай Tokio (еще есть runtime-native)

2. Хорошо ли ты подумал, отдать задачу на пул потоков или оставить в главном loop вместе с IO?

3. Не применил ли ты внутри Tokio обычный Mutex, вместо правильного mutex, совместимого с неблокирующим кодом.

4. Если создать цепочку вычислений, то на каком пуле конец цепочки будет выполнен? А если я попытаюсь результат двух future объединить и обработать, а один запущен на Tokio, а другой на пуле потоков? В той же Scala каждый сегмент цепочки получал на вход свой executor, как укажешь так и будет (хотя там никто и не ставил задачу делать zero-cost)

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.

Например в том же Rust будет куча приседаний по вопросам:

1. Какой планировщик? Например далее пускай Tokio (еще есть runtime-native)

2. Хорошо ли ты подумал, отдать задачу на пул потоков или оставить в IO?

3. Не применил ли ты внутри Tokio обычный Mutex, вместо правильного mutex, совместимого с неблокирующим кодом.

4. Если создать цепочку вычислений, то на каком пуле конец цепочки будет выполнен? А если я попытаюсь результат двух future объединить и обработать, а один запущен на Tokio, а другой на пуле потоков? В той же Scala каждый сегмент цепочки получал на вход свой executor, как укажешь так и будет (хотя там никто и не ставил задачу делать zero-cost)

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.

Например в том же Rust будет куча приседаний по вопросам:

1. Какой планировщик? Например далее пускай Tokio (еще есть runtime-native)

2. Хорошо ли ты подумал, отдать задачу на пул потоков или оставить в IO?

3. Не применил ли ты внутри Tokio обычный Mutex, вместо правильного mutex, совместимого с неблокирующим кодом.

4. Если создать цепочку вычислений, то на каком пуле конец цепочки будет выполнен? А если я попытаюсь результат двух future обьеденить и обработать, а один запущен на Tokio, а другой на пуле потоков?

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.

Например в том же Rust будет куча приседаний по вопросам:

1. Какой планировщик? Например далее пускай Tokio (еще есть runtime-native)

2. Хорошо ли ты подумал, отдать задачу на пул потоков или оставить в IO?

3. Не применил ли ты внутри Tokio обычный Mutex, вместо правильного mutex, совместимого с неблокирующим кодом.

Ок, спс. Можно поподробнее о M:N многозадачность? Как оно решает когда создавать новые потоки? Есть ли work stealing? Есть подводные камни? Опять же, например тот же Go - нету подводных камней. Просто работает. Идеально и всегда. IO-bound, CPU-bound, не важно, планировщик будет работать отлично.