Сохранять состояния программы?
Каким образом возможно сохранять состояния программы?
Обрисую ситуацию:
Есть в программе процесс, который состоит из Х этапов. Допустим, по середине одного из этапов выключился свет/перепад питания и прочая фигня. В общем, комп перестал работать.
Что необходимо сделать, что бы при запуске, программа определила на каком этапе была остановлена + в каком месте этого этапа...
Может быть какие-то дампы памяти делать или еще как-нибудь?
ЗЫ: Заранее спасибо за ответы/советы.
Если этапов много, они короткие и результат каждого этапа сохраняется на ЖД - например скачивание файла маленькими кусочками - просто можно вести лог, например:
этап №_ начался:скачано х. этап №_ закончен:скачано у.
если же результаты этапов не сохраняются в постоянной памяти - например математическое вычисление - дамп памяти как вариант пойдет.
Но тогда вопрос, есть ли какая-то дока по этому делу, как делать этот дамп, а потом с него восстанавливаться, если он имеется...?
Все это под платформу .NET.
Может быть и проще сохраняться в файле этап работы...Только опять же хотелось бы примерчик или алгоритм записа/восстановления работы.
Просто я в этом еще совсем не шарю. Это будет первая попытка создать систему восстановления программы :-D
вы работаете на шарпе с железом? а можно подробней, если не секрет!
Вероятно, вызов библиотек на C.
возможно, но все таки хотелось бы поподробней!
и в смысле хранишь состояние в памяти, есть некий объект, некоего класса, который хранит состояние железяк? тогда можно просто сереализовать данный объект с какой то периодичностью.
Да. Вызов библиотек на С.+ часть железа работает по ком-порту, по-этому можно заюзать C#, главное, правильно все написать :).
Можно. Но это состояние железки сохранит. Но у меня еще есть алгоритм, который мне тоже надо как-то сохранять, точнее на каком этапе этого алгоритма программа остановилась...вот этот момент для меня вообще не понятен.
Ну, мне бы теорию по созданию этих самых дампов :)
Т.е. есть же книжки по теории создании точек восстановления программ, или как-то так :)
Т.е. есть же книжки по теории создании точек восстановления программ, или как-то так :)
ну во первых, а вам действительно так уж прям необходимо делать этот дамп? если вы работаете через комп порт, то при отключении питания скорее всего и железяка сбросит свое состояние, то бишь алгоритм придется начинать заново. да и вообще...
во вторых, если ваш алгоритм состоит из н некоторых этапов, то не проще ли по завершению текущего и перед началом следующего писать в мего файлик номер этапа и текущие состояние железки, рабочие данные? по завершении алгоритма, если он отработал без приключений файл удалять, при старте, если файл есть, то читать его и переходить на последний удачный этап, или же как более правильно будет судить о завершении по конфигурационному файлу приложения. или можно реализовать для этого класс состоянии и сериализовать его, или использовать для этого конфигурационные данные, или банально просто писать в файл. зачем себе усложнять жизнь?
ли по завершению текущего и перед началом следующего писать в мего файлик номер этапа и текущие состояние железки, рабочие данные?
Об этом я тоже пытаюсь сказать. Да и потом (трудно однако работать телепатчески), если используются файлы, какие-то объекты ОС и пр. - всё это нужно будет переоткрывать заново при возобновлении работы, т.е. волшебный дамп просто так не поможет начать с пустого места - открытые дескрипторы потеряются в любом случае (если конечно не озаботиться предварительным дампом всей памяти ОС, вроде как это делается в спящем режиме :rolleyes:).
сорри, если продублировал твою мысль!=)
а вообще мне прям очень сильно кажется, что это все не обосновано и не нужно!
Т.е. есть же книжки по теории создании точек восстановления программ, или как-то так :)
Могу посоветовать обратиться к чему-то вроде "продолжений" (continuations). .NET не позволяет оперировать такими абстракциями на уровне платформы, потому народ изготавливает велосипеды - Undo-Redo стеки. Напротив, Mono позволяет работать с продолжениями, с помощью которых можно сотворить вашу магию сохранения состояния.
я так понял автор хочет сделать "спящий режим" для отдельной прожки, по моему овчинка того не стоит но если уж очень хочется могу предложить на пробу один изврат: что если воспользоваться файлом отображённым в память и разместить в этой памяти все структуры которыми оперирует алгоритм -- может в этом случае удастся при перезапуске автоматом вернуться в некоторое промежуточное состяние?
Вы понимаете, что при всем этом неким образом функционирует сборщик мусора?
А овчинка выделки стоит - нужно просто пользоваться соответствующими инструментами.
понимаю но не вижу в этом аргумента "против"
надо признать: при желании мы сможем разместить объекты в нужном блоке и оперировать с ними там а сложность способов освобождения этих объектов принципиально не препятствует реализации того что я предложил
-- расскажите пожалуйста про инструменты
разве кто-то накладывал ограничение использовать только управляемый код?
Посмотрите на раздел, в котором расположена тема, автор также упоминал, что использует C#.
и .Нет и Си# позволяют создавать unsafe-код так что давайте больше не будем отклоняться от темы
да вы о чем вообще!=\ даже с использование небезопасного кода возможности шарпа при работе с железом(в любом виде) столь примитивны, что о них даже упоминать не стоит, собственно как и любого языка высокого уровня.
соглашусь с hardcase, используешь шарп использую грамотно средства донет и ни каких велосипедов, все равно велосипед сей получится квадратным и ни разу не рабочим.
Рискуя удариться в флейм надо тем не менее заметить, что смысл писать на шарпе, если половина проги будет использовать unsafe mode?
Вообще, автор темы по-моему давно покинул нас...
Unsafe-код это ни разу не синоним "неуправляемого кода". Это так же не значит возможности ручного управления памятью. Unsafe-код позволяет выполнять адресную арифметику и дает некоторый аналог сиплюсплюсного reinterpret_cast-а.
Тем не менее написать ОС на C# возможно и вполне реально.
Я все не могу понять что значит "работа с оборудованием"? Любая работа с переферийным железом, как правило, сводится к чтению-записи отображенной на оперативную память внутренней памяти железяки. Если подходить к вопросу с этого бока, то ЛЮБОЙ другой язык, поддерживающий адресную арифметику, от C# практически ничем не отличается.