Здравствуйте, Erop, Вы писали:

E>Здравствуйте, LaPerouse, Вы писали:

LP>>Нет, не останется.
E>То есть я запускаю редактор, начинаю что-то редактировать в файле 1.тхт, потом отправляю редактор в гебернацию, запускаю другой, тоже редактирую 1.тхт, сохраняю, и потом вызываю к жизни первый. И что происходит?

Как захошь, так и будет. Простейший путь — не обращать внимание на измененный файл вообще. При сохранении документа, вбитого в окно, файл перезапишется и изменения, сделанные другим редактором, будут потеряны. Можно при сохранении запомнить контрольную сумму файла, и при восстановлении сказать предупредить, что файл изменен, а то и предложить смерджить изменения. Хинт — не нужно путать _данные_ и _состояние_ приложения. Остановленное приложение ничем не отличается от работающего в плане отношения к данным. Ты и в работающем редакторе можешь изменить его файл, если он не залочен. А большинство редакторов таки и не лочат файлы.

Здравствуйте, Mamut, Вы писали:

M> H>Нормальные приложения вроде и так умеют свое состояние сохранять А под виртуалкой, так вообще пачкой все сохранить/восстановить можно. В чем прикол фичи, я не понял

M> Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

Дык все это будет зависеть от реализации приложением. Ну вот Опера у меня стартует безо всяких сплешей, и вполне себе восстанавливает предыдущий сеанс работы Где рокет сайнс? Моя не понимать

Здравствуйте, LaPerouse, Вы писали:

LP>Как захошь, так и будет. Простейший путь — не обращать внимание на измененный файл вообще. При сохранении документа, вбитого в окно, файл перезапишется и изменения, сделанные другим редактором, будут потеряны. Можно при сохранении запомнить контрольную сумму файла, и при восстановлении сказать предупредить, что файл изменен, а то и предложить смерджить изменения. Хинт — не нужно путать _данные_ и _состояние_ приложения. Остановленное приложение ничем не отличается от работающего в плане отношения к данным. Ты и в работающем редакторе можешь изменить его файл, если он не залочен. А большинство редакторов таки и не лочат файлы.

От редактора зависит. Если текстовый, то да, может большинство и не лочат...

Здравствуйте, Erop, Вы писали:

E>Ну тут можно как-то выяснять какие именно процессы составляют "приложение". Например процесс и все дочерние.
Мы вот тут в соседней ветке обсуждали, что состояние приложения не всегда поддаётся чёткому определению.

E>Дык а с самими объектами, к которым дают доступ эти хэндлы, что делать, пока приложение отмораживается?
Может поддерживать специальную таблицу "открытых" файлов, не давая их удалить, пока либо приложение их не отпустит, либо юзер не удалит состояния приложений, в которых файл фигурирует как открытый.
С объектами ядра конечно существенно труднее, потому что они могут шариться между процессами. Хотя тут опять же ОС всегда знает, что чем используется и по идее может как-то разрулить ситуацию.

Здравствуйте, Cyberax, Вы писали:

C>С весёлой песней.

Ну вот и выходит "тут работаю, тут не работаю, а тут я рыбу заворачивал"

Здравствуйте, koandrew, Вы писали:

C>>С весёлой песней.
K>Ну вот и выходит "тут работаю, тут не работаю, а тут я рыбу заворачивал"

Ну, просто, авторам приложений будет что поотлаживать...

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Erop, Вы писали:

E>>Ну тут можно как-то выяснять какие именно процессы составляют "приложение". Например процесс и все дочерние.
K>Мы вот тут в соседней ветке обсуждали, что состояние приложения не всегда поддаётся чёткому определению.

E>>Дык а с самими объектами, к которым дают доступ эти хэндлы, что делать, пока приложение отмораживается?
K>Может поддерживать специальную таблицу "открытых" файлов, не давая их удалить, пока либо приложение их не отпустит, либо юзер не удалит состояния приложений, в которых файл фигурирует как открытый.

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

K>С объектами ядра конечно существенно труднее, потому что они могут шариться между процессами. Хотя тут опять же ОС всегда знает, что чем используется и по идее может как-то разрулить ситуацию.

Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.

Здравствуйте, LaPerouse, Вы писали:

LP>Еще один вариант — зарегистрировать обработчик исключительной ситуации, когда хэндл вдруг стал недействительным. Для приложения все будет выглядеть так, как будто хендл был и внезапно исчез, чего конечно не может быть в обычном работающем приложении. По факту — вместо одного АПИ получаем другое, правда, пользоваться им проще (сохранение нахаляву).
Не, этот подход уж очень кривой — хэндл не может просто так исчезнуть (не забываем, что мы пытаемся сдизайнить систему, которая будет полностью прозначна для приложения). Лучше уж мой подход, и при попытке снести такой файл выдавать "Сорри, этот файл использется в приложении А, чтобы удалить его вам надо закрыть файл из этого приложения". Поскольку всё адресное пространство будет уже готово, приложение поднимется моментально (точнее настолько быстро, насколько быстро файл дампа успеет считаться с диска, хотя здесь можно туро сделать маппинг файла на всё адресное пространство — тогда даже писать ничего не придётся — механизм уже есть в ОС

LP>Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.
У них сейчас и так сквозная идентификация...

Здравствуйте, Erop, Вы писали:

E>В принципе, можно себе что-то такое помыслить. Например, ОС может сохранять адресное пространство приложения как есть + как-то хитро записывать свои структуры данных, имеющие отношения к этому процессу. А потом, типа восстанавливать.
E>Но, IMHO, это малореально реализовать на практике. Что делать с PID'ами, с файлами, с соектами и т. д.?
Блин, оно уже много лет как работает.

Здравствуйте, Mamut, Вы писали:

M>Что андроид?

Читай его СДК.

M>При чем тут хибернейт?

При том, что он решает весьма похожую задачу. Решает прямо здесь и сейчас.

M>

Для слоупоков: хибернейт в макоси есть

Как выяснилось, да, есть. Называется, правда, Safe Sleep — попробуй догадайся. Выходит обычный слип нифига не сейф ? И да, включается сторонней тулзой, в самой ОС его не видно (потому я и написал, что его нет).

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, LaPerouse, Вы писали:
K>Не, этот подход уж очень кривой — хэндл не может просто так исчезнуть (не забываем, что мы пытаемся сдизайнить систему, которая будет полностью прозначна для приложения). Лучше уж мой подход, и при попытке снести такой файл выдавать "Сорри, этот файл использется в приложении А, чтобы удалить его вам надо закрыть файл из этого приложения". Поскольку всё адресное пространство будет уже готово, приложение поднимется моментально (точнее настолько быстро, насколько быстро файл дампа успеет считаться с диска, хотя здесь можно туро сделать маппинг файла на всё адресное пространство — тогда даже писать ничего не придётся — механизм уже есть в ОС

Правильно — замороженное приложение по отношению к ресурсам должно вести себя так же, как и работающее.

LP>>Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.
K>У них сейчас и так сквозная идентификация...

А один и тот же идентификатор объекта не может быть присвоен повторно другому объекту (после освобождения)? Уже все забылось, лет 5 весьма далек от системы

Здравствуйте, Mamut, Вы писали:

H>>Нормальные приложения вроде и так умеют свое состояние сохранять

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

M>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

Хочу! Хочу такую фичу. Вот в Ондроеде сделали шаг к этому. Если у Эпла получится поставить в нужную позу-направление девелоперов и юзерам это понравится, глядишь и в остальных ОС прикрутят.

Здравствуйте, LaPerouse, Вы писали:

LP>А один и тот же идентификатор объекта не может быть присвоен повторно другому объекту (после освобождения)? Уже все забылось, лет 5 весьма далек от системы

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

Здравствуйте, Cyberax, Вы писали:

C>Блин, оно уже много лет как работает.

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

А вот если мы прогу отмораживаться отправим, то что с теми файлами станет-то?

Здравствуйте, Mamut, Вы писали:

M>Вот это не знаю Пока что деталей нет, есть только "we are working on it"

Я собственно не с целью войн спрашивал просто не могу себе представить механизм, тупо в текстовом редакторе редактировал файл, сохранять мне его СЕЙЧАС пока рано, усыпил ее, она себе какую-то копию "черновика" оставит? А если файл изменился, ей еще и нужно помнить какой оригинал мы редактировали? Это я в самом простом виде, а если это не однодокументная пользовательская программа, а что-нить покруче? Как бы в обычном-то хубернайте сначала она запустится и не даст никому надругаться, а тут мы ее одну усыпили, а проводник-то допустим работает, вот и интересно что тут придумать можно.

Здравствуйте, Mamut, Вы писали:

M>>>>>А ну ка, кто таким может похвастаться?
КБ>>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?
M>>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.
КБ>>Это в любой ОС это есть

M>А ну ка расскажи.

В винде например это CreateFile/WriteFile/ReadFile. Общесистемный и доступный для всех. Позволяющий приложениям сохранять свое состояние.

Здравствуйте, nullptr, Вы писали:
N>Здравствуйте, CreatorCray, Вы писали:
CC>>Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.
N>Камень правильный, огород — нет. Отсутствие многозадачности — это к iOS. А тут речь про MacOS.
Моногозадачность в iOS есть. Но не для всех приложений. Что есть правильно и кошерно.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Mamut, Вы писали:
КЛ>[]
КЛ>WM_QUERYENDSESSION?
КЛ>я что-то упустил, или у кого-то рак мозга?

Предлагается подумать на тему что такое WM_* и нахрена приложению заниматься серилизацией самого себя, когда система может сделать hibernate процесса а после его восстановить, а так-же подумать на тему какой вариант будет надежнее и быстрее.

Здравствуйте, Ларик, Вы писали:

Л> в текстовом редакторе редактировал файл, сохранять мне его СЕЙЧАС пока рано, усыпил ее,
Л> она себе какую-то копию "черновика" оставит?
останется тот документ, который был в памяти на момент гипернейта.

> А если файл изменился
файл на диске не имеет, по большому счету, ни какого отношения к тому что загружено в память.

> ей еще и нужно помнить какой оригинал мы редактировали?
с какого перепуга?!

Л> обычном-то хубернайте сначала она запустится и не даст никому надругаться, а тут мы ее одну
Л> усыпили, а проводник-то допустим работает
а без хибернейта такое не возможно? редактируешь ты исходник в visual studio, а потом полез и FAR-ом его-же поправил...

M>>>>Причем тут FF?
E>>>При том, что они вполне обошлись без спец. API...
M>>Правильно, изобретя собственный велосипед. МакОСь предложит единый API
A>вот ты тут уже стопицот раз сказал "API".
A>а *что именно* будет делать этот API?
A>а) уведомлять приложения что им надо сделать savestate/restorestate
A>б) собственно делать savestate/restorestate (и приложениям надо будет лишь дернуть эти функции)

A>если не б), то это велосипед, увешанный баянами

А мы посмотрим Пока ничего конкретного нет