>Отдельный вопрос - при чём тут вообще риалтайм

Я в начале задался вопросом - не получится ли слишком большой плата за слив состояния, ведь есть приложения прерывание которых нежелательно. Изначально не видя решения такого снапшота у меня были сомнения не слишком ли дорого это обойдется, но с COW согласен, проблем вобщем нет особых, поэтому вобщем вопрос снят.

Про файлы. Есть механизм транзакций в той-же NTFS, который например используется для снятия снапшота при бэкапе всей системы, физически как-то черед shadow копии работает. Т.е. технически вроде как и с файловой системой можно все сделать, но не бесплатно конечно.

По их методе можно так - файл = объект с одним полем - массив байт, интерфейс доступа аналогичен обычным операциям. Интересно как они будут переваривать такие объекты размером больше памяти, очевидно подкачка должна иметь место. Для такого типа объектов мы можем снять снапшот, получим наш файл в обычном понимании.

* * *

В целом все туманно и мне кажется что правильнее было продемонстрировать на существующем managed framework свою концепцию, хотя может этого и недостаточно - мы ведь не знаем как оно работает. Но я подозреваю, что достаточно, просто планы наполеоновские.

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

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

Собственно, да - этого должно быть достаточно. Более того, если слово "объект" заменить на слово "блок памяти" (а все эти CoW - они ведь вполне низкоуровневые), то получается что такого рода "неубиваемость" можно просто прикрутить к винде - пусть она точно так же бэкапит память. Можно для отдельных приложений - мне необязательно "поднимать", скажем, браузер - он и сам поднимется если что, а вот какой-нибудь ворд-эксель-корел-фотошоп - не помешало бы :-)

Надо толкнуть идею микрософту. Пусть в windows 8 реализуют :-)

Да, выходит, что можно попытаться реализовать подобное поведение для существующих систем, что мне кажется очень интересным вариантом.

сделать свой яп и vm практически проще, чем заэмбеддить готовое. не факт, что правильней, но - проще.

Что проще - спорить не буду, т.к. этот вопрос требует проработки, на которую я конечно не претендую.

Что я понял для себя - реализовать подобное можно и для существующих систем. Вы выбрали свой способ достижения цели и стратегия видимо еще вызвана коммерческой составляющей. Очень большим минусом будет необходимость переписывания софта. Пример iphone конечно показателен, но масштабы Apple - это заоблачные дали, да и в основе там вроде лежит unix, а не что-то совершенно ни на что не похожее.

Так или иначе, удачи!

Спасибо.

Реализовать это в виде костыля можно много для чего, но как бы идея системы в том, чтобы отряхнуть мир от костылей.

Переписывать, строго говоря, не нужно - во всяком случае, мы планируем подхватить весь java (+другие JVM-языки) софт, плюс javascript и php. Это - минимальная задача.