Данные и логика в отдельных процессах

[Алексей Гринь]

Вот есть мысль хранить документ в RAM отдельно от всей логики программы.
То есть существуют два процесса: процесс, хранящий модель документа, и процесс для всего остального (логика, UI и т.д.). Общаются они, стало быть, между собой с помощью средств межпроцессного взаимодействия, доступных на ОС.

Зачем это нужно? Ну, теоретически, если процесс логики крэшится из-за ошибки в коде, или как-то повреждает свою память, то умирает только процесс логики; процесс, содержащий модель редактируемого документа, продолжает существовать, так как он полностью изолирован. При крэше достаточно автоматически перезагрузить упавший процесс, и он автоматически подхватит забэкапленную модель документа из висящего процесса модели. Таким образом, данные не теряются и не повреждаются.

Так вот, не могу правильно загуглить примеров на подобное. Это вообще разумно, или проще бэкапить на жёстком диске? Если бэкапить на диске в том же процессе, то, всё же, не исключено повреждение памяти, если ошибка в логике каким-то образом затрагивает структуры и код, которые занимаются самим бэкапированием на жёсткий диск, т.е. 100% гарантии сохранности данных нет. Плюс бэкап на жёсткий диск должен производиться через промежутки времени, а не постоянно, поэтому бэкап может быть outdated.
Не знает ли кто случайно, делают ли нечто подобное известные программы (типа OpenOffice, может быть), может быть, это вообще стандарт там?

[Python]

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

[Алексей Гринь]

Повторно использовать данные, оставшиеся в памяти после падения процесса, мне кажется, нецелесообразно: как минимум, они могут быть повреждены и вызывать ошибки

Ну так по моей задумке процесс модели документа — это своего рода сервер, который принимает сериализуемые сообщения на изменения документа. Повредить документ вне сервера просто нереально, потому что мы не напрямую изменяем память, а только просим сервер (процесс модели документа) сделать это.

а не тот же код, наступающий на те же грабли

Код крэшиться может не напрямую из-за документа, а из-за каких посторонних причин на стороне клиента (out of memory, ошибки в логике обработки документа с помощью какой-то опр. функции, ошибки в UI). То есть программа юзабельна, если не делать определённых действий... Если случайно юзер напоролся на баг и всё покрешилось, то данные гарантированно восстановятся.

[Bhudh]

А каким образом можно загрузить код в область памяти, не занятую данными? Это надо адрес данных в памяти тоже где-то бэкапить.

[Тайльнемер]

Вот есть мысль хранить документ в RAM отдельно от всей логики программы.

Интересная мысль!
Я, правда, ни разу не пробовал заниматься межпроцессной коммуникацией, так что ничего подсказать не смогу.

А каким образом можно загрузить код в область памяти, не занятую данными? Это надо адрес данных в памяти тоже где-то бэкапить.

Bhudh, я не понял, о чём вы.

[Bhudh]

Ну ситуация: код загрузил данные в кучу, поставил себе указатель на них... И крашнулся. Данные по условию остались в памяти. А указатель где?

[Тайльнемер]

Но Гринь же не это предлагает.

[Triton]

Вот есть мысль хранить документ в RAM отдельно от всей логики программы.
То есть существуют два процесса: процесс, хранящий модель документа, и процесс для всего остального (логика, UI и т.д.). Общаются они, стало быть, между собой с помощью средств межпроцессного взаимодействия, доступных на ОС.

Вы изобрели клиент-серверную модель.   

[Алексей Гринь]

А каким образом можно загрузить код в область памяти, не занятую данными? Это надо адрес данных в памяти тоже где-то бэкапить.

Ну ситуация: код загрузил данные в кучу, поставил себе указатель на них... И крашнулся. Данные по условию остались в памяти. А указатель где?

Не уверен, что что-то понял (по-английски, может быть, понял бы, так как русскую терминологию с трудом читаю).

При такой системе обращаться к документу можно только с помощью id'ов документа, а не с конкретными указателями. Например, если есть документ в стиле "logical_path/document.doc", то чтобы что-то с ним делать, нужно получить его id. Конечно, крэшащаяся программа может предъявить не тот id, но т.к. доступ сериализован, сервер сразу же это просечёт (команда GetDocId ни разу не возвращала такой id для этого клиента) и тогда сервер ответит клиенту нужным errorcode'ом, что просигнализирует: ты какой-то болезный, иди прокрэшься и перезапустись. При перезапуске (и при старте) клиент всегда пытается найти висящий в памяти процесс документной модели и приконнектиться к нему. Процесс тот помнит, что последним незаконченным документом был "logical_path/document.doc", поэтому предложит перезапустившемуся клиенту заново им инициализировать свой View (в смысле Model-View-Controller).

Алсо, документ должен храниться в каком-то стандартизированном DOM'е, а не быть просто тупым набором байтов. В моём случае у меня есть простенький прототип в около-JSON'овском стиле (незамысловато назвал Object Hierarchy Markup). Тогда и команды изменения документа довольно простые: «найди вот этот вот элемент иерархии и замени его вот этим вот элементом», или «вот сюда вот вставь новую ветку иерархии». Межпроцессные команды я думаю сделать текстовыми (ровно как и сам DOM), т.к. формат документа базируется на текстовости ради простоты.

Вот я даже и не знаю, это прикольно всё реализовывать, но нужно ли. Может быть, всё-таки, простой бэкап suffices. С другой стороны, если ещё сохранять всё в виде delta-изменений, расшарить процесс другим машинам в сети (то есть изначально через сокеты производить прослушку), да периодически бэкапить DOM на жёсткий диск — получим свой собственный сервер с блэкджеком и шлюхами для совместного редактирования документа с возможностью отката изменений...

[Алексей Гринь]

Вы изобрели клиент-серверную модель.   

Так я ничего не изобретал, это всё известные вещи. Просто я не знаю, использует ли известный софт такую модель для оффлайна.

[Triton]

Вы изобрели клиент-серверную модель.   

Так я ничего не изобретал, это всё известные вещи. Просто я не знаю, использует ли известный софт такую модель для оффлайна.

Для оффлайна вряд ли. По крайней мере, не вспоминается ничего на этот счёт.
Думаю, экономическая целесообразность отсутствует.

[Алексей Гринь]

Думаю, экономическая целесообразность отсутствует.

В смысле? Тут же не экономическая целесообразность, а целесообразность стабильности. На первых порах особенно, кто знает, как часто будет крэшиться на других компах. Закрэшилось — ну так и само сразу же перезапустилось; документ целый, продолжай с того же места, не сильно напрягает.
Скорость общения между процессами — несколько гбитс, для моих задач норм.

Что касается унификации интерфейсов для оффлайна и онлайна, я вот вспомнил, что в совр. версиях Minecraft'а оффлайн-режим это на деле локалхостный сервер. Так что разумно было бы сделать такое «на вырост» (оффлайн — это изначально локалхостный сервер), чтобы потом не пришлось переписывать код (как в том же Minecraft).

Может быть, всё-таки OpenOffice делает так  Если запускаю его, то он сразу три процесса создаёт. Как раз в моей модели три процесса и нужно: 1) контрольный процесс, запускающий остальные процессы и перезапускающий их в случае крэшей 2) процесс логики и UI 3) процесс документной модели.

[Triton]

Думаю, экономическая целесообразность отсутствует.

В смысле? Тут же не экономическая целесообразность, а целесообразность стабильности.

Вот стабильность и не стоит затраченных денег для большинства приложений.
Там, где mission critical, оценки, понятное дело, иные. Взять тот же QNX, который весь клиент-серверный начиная от драйверов, ибо микроядерный.

[Triton]

Что касается унификации интерфейсов для оффлайна и онлайна, я вот вспомнил, что в совр. версиях Minecraft'а оффлайн-режим это на деле локалхостный сервер. Так что разумно было бы сделать такое «на вырост» (оффлайн — это изначально локалхостный сервер), чтобы потом не пришлось переписывать код (как в том же Minecraft).

Да, при проектировании на вырост это разумно. Собственно, это первое, что пришло мне на ум при чтении топика.

Может быть, всё-таки OpenOffice делает так  Если запускаю его, то он сразу три процесса создаёт.

У меня так:
> 16598 /bin/sh /usr/bin/lowriter
> 16600 /usr/lib/libreoffice/program/oosplash --writer
> 16615 /usr/lib/libreoffice/program/soffice.bin --writer --splash-pipe=5

Имхо, по названиям видно, что нужен только soffice.bin. Если его вручную запустить, запускается и работает.

[Алексей Гринь]

Вот стабильность и не стоит затраченных денег для большинства приложений.

Ну мой софт, подразумевается, будет оперировать большим количеством данных, в том числе, с кэшем промежуточных представлений в RAM (кэш принадлежит логике и UI, а не самому документу), поэтому out of memory вполне могут быть частыми, особенно на более слабых компьютерах. В похожей программе у меня частенько внезапно бывают out of memory, и тогда теряются последние изменения, что реально бесит.

[mnashe]

простой бэкап suffices

Довлеет?

[Алексей Гринь]

Довлеет?

Хватает. Я думаю по-английски, иногда аналогов русских вспомнить не могу.

[Чайник777]

Довлеет?

Хватает.

А довлеть когда-то и значил to suffice 

[mnashe]

А довлеть когда-то и значил to suffice

У «хватает» в принципе то же значение, но управление другое (логический субъект при нём не в номинативе, а в партитиве).

[Sutinator]

Я так понимаю, хранить документ в памяти необходимо В ЦЕЛЯХ редкого обращения к диску, а т.ж. скорости i/o?

На всякий случай: MS Office восстанавливает все несохранённые результаты работы после крашей.

Если я правильно понял чего Вы хотите (проекция ФС в ОЗУ), то должно помочь такое средство, как RAM drive - (wiki/en) RAM_drive

[Sutinator]

Наверно не все так как ув. Гринь, могут не то чтобы думать но и осмысленно читать на английцких языках. По-Русски:
(wiki/m) RAM_drive

[Алексей Гринь]

Я так понимаю, хранить документ в памяти необходимо В ЦЕЛЯХ редкого обращения к диску, а т.ж. скорости i/o?

Нет. Цель — не хранить документ в памяти (вместо диска); цель — хранить рабочее представление документа в месте, изолированном от прочего кода. Под рабочим представлением документа я имею в виду некое дерево структур, с которым программа может работать в конкретный момент времени. Разумеется, документ можно сериализовать и сохранить на диск, всё-такое. Я не о том. Я, наверное, конечно, over-engineer (переинженериваю?), но хостить сам документ в том же процессе, что и логика — не 100% безопасно. Если в программе есть ошибка типа переполнения буфера, то забагованный код может повредить рабочую модель документа в памяти, и бэкапь не бэкапь — забэкапишь повреждённый документ. И прощай работа нескольких часов, а то и дней. Конечно, можно применять что-то вроде CRC для верификации структур — но не муторнее ли это? Плюс, при CRC-верификации мы только можем сказать, что данные повреждены, мы не можем предостеречься от этого так, чтобы этого не происходило вообще.

[Sutinator]

Уфф, мудрено...Что из себя представляет рабочая область?
Нужно специально спроектированное приложение, некая студия: процесс для отображения древа проекта, и отдельно вызываемые утилиты для работы с разными данными его частей.
См. также COM и DDE.

пс: не думаю, что есть готовые решения. Берите напильник и пилитепишите.