Himik писал(а):
dzavalishin писал(а):
Это смотря кем. Впервые начала встречаться лет 40 тому назад, наверное.
Я и говорю, что по некоторым моментам - это движение в прошлое. Какова периодичность сохранения контекста? Если только на выходе - это ещё пол беды. Если и во время работы, то это будет тормозить работу, если не использовать специальных алгоритмов оптимизации. Если такие придуманы, то хотелось бы услышать.
PS: Они СДЕЛАНЫ пару лет тому назад, блин. "придуманы".
Трёп, трёп, трёп... я пришёл сюда найти людей, которые готовы превращать "сложно" в "сделали!", а не рассуждать о непреодолимости сложностей.
Персистентность - пройденный этап. Синхронизация персистентных тредов - вот РЕАЛЬНАЯ проблема на сегодня. Сделать мьютексы, которые хранят состояние в персистентной памяти (а, значит, обращение к стейту мьютекса может вызвать переключение контекста и блокировку треда во время !!запирания!! мьютекса) - вот это - задача на поломать голову.
Или вот задача реализации примитивов синхронизации jvm без добавления к каждому объекту ещё одного пойнтера.
Или вот создание распределённой среды хранения классов в сети, с цифровыми подписями, и всей инфраструктурой.
Или вот реализация персистентных юникс-процессов - и персистентность есть, и процессы - надо только аккуратно поженить.
Или вот написание офлайн-сборщика мусора для снапшота. Вообще банальная штука - НО - он должен собирать мусор на терабайтном диске, не особо грузить дисковую подсистему и укладываться хотя бы в пару дней. А лучше - иметь generations и часовой roundtrip на молодом поколении.
Или вот сделать в байткоде поддержку функциональных объектов и автоматическое распараллеливание исполнения для немутабельных веток кода-данных.
Или вот починить arm-овский порт, который сейчас живёт не больше минуты, а потом - взрыв на макаронной фабрике, клочки по закоулочкам...
"в прошлое". Движение - это всегда в будущее. В прошлое можно попасть только не двигаясь.