Ещё о Фантоме. Представляю заинтересованным концепцию ленивых нитей.

Идея вот в чём. Иногда запуск нити не обязателен семантически, но лишь возможен и/или желателен, плюс объём выполняемого в потенциальной нити кода недостаточен, чтобы так уж настаивать на запуске нити для его выполнения. В такой ситуации уместно дать системе лишь хинт - указать на то, то вот то-то и то-то может быть сделано параллельно основному коду, особенно, если под руку подвернётся простаивающий процессор в SMP-компьютере.

Решать же - запускать нить, или исполнить код в рамках "отчей" нити - можно предоставить операционной системе. Заявка на запуск такой нити - это всего лишь один mov - помещение в специальный стек запросов адреса элемента в основном стеке, где начинается контекст новой нити. Сам же код нити в этом случае запускается обычным вызовом подпрограммы. Если в процессе её работы контекст ни разу не переключался, никакой второй или третий процессор не освобождался и вообще ничего существенного не произошло - нить не состоится. Код её отработает, как простая подпрограмма, а при возвращении снимет запрос на образование нити.

Если же мы и так переключились в ядро - из-за системного ли вызова, или у нас обнаружился избыток процессорной мощи, то заглянем в стек запросов на ленивые нити. Есть запрос? Оформляем уже работающий код "ленивой" нити как настоящую нить, а в той нити, что породила её симулируем возврат в точку, где ленивая нить была запущена. С этого момента она работает параллельно и в своём контексте.

В чём прелесть такой схемы? Она позволяет резко понизить стоимость запуска нити (полный запуск случается не всегда и только если контекст переключился на ядро по иной причине, а в таком случае запустить нить - дёшево), а значит меньше задумываться о том, уместно ли их применение там и тут.

Придумана она была по смешной причине. На одной из стадий обдумывания Фантома я пришёл к вопросу, не имеет ли смысла запускать в отдельных нитях просто все методы вообще и всегда. Первой реакцией была мысль, что это дико дорого, но как раз эту проблему удалось решить "ленивыми" нитями. Впрочем, от идеи непрерывного нитерождения я отказался по банальной причине - пож такую систему было бы нелегко программировать, а я, в конце концов, хотел бы вовсе обратного. :-)

Используются технологии uCoz