Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2009-09-09 23:19:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Фантом раз, фантом два...
     Я всё о Фантоме. Который "от dz".

     ОС Фантом настолько сурова, что в ней нет файлов. Документ, с которым в данный момент работает пользователь, даже в обычных операционках во время работы не "лежит на диске", а висит в памяти в виде пучка объектов. Система (Фантом), в силу, тсзть, дизайна, гарантирует долговременную сохранность состояния приложения (и, естественно, всей этой грозди объектов) - а раз так, то как бы нет потребности эту гроздь объектов переливать из одной формы (память) в другую форму (последовательность байт), и обратно. Привязали к этой грозди иконку на десктопе - пользователь кликает иконку, у него всплывает документ - красота, и никаких файлов!
     С точки зрения dz, отсутствие файлов, а равно и отсутствие необходимости чего-то куда-то сохранять, есть плюс разработчикам: не надо писать процедуру разборки "внешнего" формата "документа" во внутренний формат "как оно лежит в памяти", не надо писать обратную процедуру - сборки внутреннего представления в поток байтиков. И это как бы верно. Если бы не одно "но" - даже сам dz понимает, что без файлов, собственно, обойтись всё равно не удастся - мир вокруг, увы, слишком завязан на "одномерные потоки данных", и даже при передаче документа между двумя "фантомами" в промежутке может возникнуть какой-нибудь ужас, типа флэшки с FAT'ом, электрописьма с аттачем, или банального веб-сайта с пипкой "download". И тут-то файл и понадобится.
     Но это фигня! Если документ - не более чем "состояние приложения" (т.е. фактически множество объектов, принадлежащих приложению, плюс совсем чуть-чуть служебной информации, а может быть и без неё), то сохранение/загрузку документа можно сделать единообразным образом, и вообще поручить её системе: нужно сохранить документ - просим систему сделать "дамп состояния программы", нужно загрузить - просим "восстановить состояние из дампа". Дамп - обычный файл, который можно передавать куда надо, разработчику приложения думать ни о чём не надо - достаточно дёрнуть ровно одну ниточку в системе, а бонусом - вместе с документом при этом автоматом будет сохраняться всякая приятная мелочёвка типа undo-буфера и запомненных строчек в полях ввода. Недостатки тоже есть, но они решаемы :-)
     Есть только один нюанс. Для того, чтобы сохранять "гроздь объектов" - вовсе не нужен фантом. Никто не мешает приделать такую возможность к любому современному "объектно-озабоченному" языку. Более того - в принципе это приделываемо к любой программе, необязательно "объектно-ориентированной" - просто "объектом" там будет нечто другое. И мы поимеем один из бонусов фантома (заментый, правда, скорее разработчикам чем пользователям), не имея собственно фантома.

     Второй бонус Фантома (заметный пользователю, а не разработчику) - возможность "упасть-отжаться": прозрачное (без остановки приложений) постоянное "автосохранение" мгновенного слепка состояния системы (и приложений). Радость при этом в том, что даже при внезапном пропадании электричества - теряется не "вся работа с момента последнего сохранения", а только последние несколько минут, а то и секунд: после загрузки системы она восстанавливается по состоянию "на момент последнего снапшота". При этом для снятия снапшота, напомню, не требуется остановка приложений.
     Как это реализовано - особо не афишируется. Но, как мне кажется, особо фантазировать не получится. В момент начала снятия снапшота мы выставляем всем "объектам" флажок "не сохранён". Далее - бежим по всем объектам, сохраняя их, и сбрасывая флажки. Если приложение хочет изменить (записать в) какой-то объект, помеченный как "несохранённый" - система автоматически делает copy-on-write - дублирует объект, приложение начинает работать с объектом, а система, когда дело доходит до сохранения именно этого объекта, сохраняет копию (и убивает её - у нас остался оригинал). На самом деле всё чуть сложнее - снапшоты надо делать инкрементально (т.е. к объекту привязать что-то вроде dirty flag, и при его чистоте - не пересохранять объект, а делать ссылку "старая копия вполне годна"), снапшота должно быть два - один "в стабильном состоянии", второй "в процессе сохранения", а "флажки сохранённости" необязательно тупо переворачивать у всех объектов, достаточно в начале цикла сохранения переопределить их интерпретацию на противоположную. Впрочем, это подробности.
     Многие программы сами имеют функцию автосохранения. Полезную - когда документ небольшой, и жутко раздражающую, когда документ разрастается на сотни мегабайт и сохраняется минутами. Раздражающую ровно потому, что на время сохранения программа блокируется - действительно, сложно одновременно сохранять текущее состояние, и вносить в него изменения.
     Однако - опять вспомним фантом. Ничего не мешает делать фантомовское "прозрачное сохранение" в пределах одного отдельно взятого приложения. Механизм тот же - сохранение всего по кругу, CoW для несохранённых объектов при попытке их изменения, инкрементальность сохранения. После этого "автосохранение" в данном приложении начнёт работать волшебным образом: если я сижу и набираю текст (изменения - не более десятков байт в секунду) - автосохранение будет успевать сохранить изменения буквально в реальном времени, и только если я делаю большие изменения - автосохранение будет "отставать" на заметное время. В любом случае меньшее, чем обычное автосохранение всего документа "раз в пять минут", и не блокирующее на это время приложение. А заодно и обычное, не автоматическое, сохранение станет халявой: просто прекратили изменять документ, дождались конца цикла автосохранения, выдали окошко "всё ок" :-)
     Правда, есть нюанс: для достижения такого счастья в обязательном порядке понадобится поддержка со стороны языка программирования (среды выполнения, возможно даже системы). Поскольку, как мне кажется (могу ошибаться), на современных языках подобные извраты с CoW естественным образом не пишутся, а противоестественные методы - угробят идею в зародыше. Но, опять же, это возможно и без создания новой ОС - модернизацией уже существующих.

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


(Читать комментарии) - (Добавить комментарий)


[info]dibr@lj
2009-09-10 09:23 (ссылка)
Не свопить (это не свопинг, это другое), и не всю (только изменяемую) :-) И "постоянно" - не значит "очень плохо": можно (и нужно) ввести ограничение вида "потреблять на снапшоты не более N% ресурсов" - тогда шуршать оно будет, но сильно мешать работе уже не должно.

Хотя непрерывный(!) шорох винта (а так оно и будет, поскольку в системе всегда что-нибудь да меняется) - не для слабонервных...

Кстати, "своппингу" это тоже поможет: объекты, не помеченные как "несохранённые", можно при необходимости выкидывать из памяти молча :-) То есть, это и сейчас делается (вытесненная на диск страница дискардится не сразу, а когда понадобится память), тут просто добавится принудительное массовое вытеснение страниц на диск :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rain251@lj
2009-09-10 09:30 (ссылка)
опять пошло по кругу :)) в том виде как сейчас с приложением которое считает х=х+1 такой "свопинг" будет работать. с чем-то более тяжелым придется свопить именно всю память или довольно большой ее кусок. для пользователя в общем нет разницы что свопить 2 гига или 4. и то и то одинаково медленно в терминах уборщица ткнула шваброй в пилот а я не сохранялся. в таком виде оно и сейчас есть - и во многих программах, да и макрос повесить на ктрл+с несложно..
да и винты при такой нагрузке будут лететь стаями. в общем пока вижу идею как бредовую и малоприменимую... проще уж поставить копию оперативы+автономное питание и свапить туда. дорого, но зато быстро и надежно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-09-10 09:44 (ссылка)
По порядку :-)

Шуршать винтом будет непрерывно в любом случае, даже если в системе просто мигает двоеточие в часах. Это проблема, причём для пользователя скорее всего вполне серьёзная. Для системы - не очень серьёзная, потому что можно ограничить затрачиваемые на это ресурсы. Сильно ли изменится ресурс HDD - неочевидно: пластины крутятся в любом случае, головка пластин штатно не касается...

А мы обсуждаем фантом, современные ОС, или мою версию "автосохранения"? А то я как-то уже нить потерял :-) За фантом пусть dz отдувается, за механизм vm в современных ОС я уже сказал - "это полезно", за автосохранение - ну, оказывается подобный "инкрементальный автосэйв" уже реализован в отдельных приложениях, как именно не знаю, но чудес быть не может в любом случае: если я изменил большой кусок данных, сохраняться он будет долго, а если одну букву - можно сохраниться быстро.

А решение вида "дёшево и сердито" давно существует - это UPS. Подпереть систему на время принудительного гибернейта, после чего обессиленно упасть. Правда, последние два раза мой ippon почему-то "не смог" удержать компьютер - свет мигнул, упс пискнул, комп перегрузился. Батарейку что-ли проверить, может она уже превратилась в собственный массогабаритный макет...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rain251@lj
2009-09-10 09:53 (ссылка)
я уже сам нить потерял чего обсуждаем :)) ну да ладно))
ресурс хдд меняется сильно - на своем опыте. раньше в бедной редакции компы дизайнеров жили в постоянном свопе. и там винты летели НАМНОГО чаще, чем такие же в рядом стоящих компах без таковой нагрузки. а с учетом что ресурс нынешних винтов не тот что был раньше, увы.. (да, раньше и деревья выше и трава зеленее и винты долгожительнее были ))

о, иппона мать. не проверяй - меняй сразу. у них батареи больше 1.5-2 лет не живут, даже если ни разу не использовались. у меня этих иппонов штук 30. сначала перестает держать при падении, через некоторое время просто не включится.
чудно что 12/7 аккум для них в компмагазине стоит 1200, а точно такой же в пожарных и прочих сигнализациях - 400 руб ))

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-09-10 10:08 (ссылка)
У меня есть пять штук 12/4, купленных когда-то для других целей. Привяжу проводочками снаружи, заодно менять проще будет :-)

А вообще, я пожалуй задумаюсь. При таком сроке службы, и при сегодняшних ценах на литий - может, переделать УПС на литий? Или автомобильный аккум под стол поставить...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rain251@lj
2009-09-10 10:14 (ссылка)
под литий наверное затруднительно будет, там же схема простая - заряд идет постоянно, слишком много городить придется.. про автомобильный на форуме иппона были топики вроде кто-то прикручивал. надо охлаждение прикручивать - их конструктив не рассчитан на такое время работы - инвертер сдохнет..
не вижу смысла ни в том ни в том. раз в 2 года 400 рублей можно потратить, хотя бы для цивильного внешнего вида. а литий через 2 года тоже вполне может потерять большую часть емкости..
12/4 маловато будет. иппоны и так не шибко эффективные на новом аккуме 7а/ч комп с лсд монитором держат 5-8 минут. а с 4а/ч хорошо бы гибернейтнуться успело..

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]dibr@lj
2009-09-10 10:26 (ссылка)
Надо замерить, какое напряжение будет на аккуме в стационарном состоянии. Литий чрезвычайно капризен, скорее всего вопрос с литием отпадёт сам собой. Но практика показывает, что литий, при правильном использовании, живёт весьма долго, так что "эту мысль я буду думать".

А 12/4 у меня пять штук, и они уже спаяны/склеены воедино, так что поставлю снаружи, "дизайн" комнаты сильно не испортится...

(Ответить) (Уровень выше)


(Читать комментарии) -