www.mudconnector.su

Ну что же... я уже применяю это в своем движке ... и скажу так ... это работает.

kernel error, blue screen of death - это ошибки уровня ядра ОС. Это в основном проблема
с железом и драйверами. Тут вины программы нету, неважно как она написана.
От этих ошибок, как и от power failure уберечься конечно нельзя исключениями.
Тут можно применять другой какой нибудь подход - например дамп мира в страничный файл.

А вот disk write error, database index corrupt, и даже divide by zero - обработке в общем
поддаются. Исключения помогают от ошибок в программе, которые могут приводить к падению.
Особенно это касается работы с указателями с и с++.

Хоть убей не понимаю, что такого ты планируешь делать в обработчиках этих ошибок.
поймать-то их можно... но к сожалению, когда речь доходит до того, чтобы написать
реакцию очень быстро приходит в голову мысль, что "начались такие дебри, из которых
живым не вернутся". Спору нет, все можно... как говорил мой шеф "за все время и
все деньги мы сделаем всю работу". Но когда нет этого "всего" я не вижу смысл инвестировать
кучу времени в то, чтобы написать на 1 строку кода 10 срок обработчиков ошибок, и убедиться,
что не все сценарии были продуманы.

А зачем многопоточность применяете ? Цель какая ?
Не хватает производительности ?

У меня обработчики исключений - работают на одну цель - остановить сервер без потери данных.
После возникновения ошибки - она ловится в обработчике. Обработчик останавливает основной
цикл сервера и после этого сервер переходит на сохранение текущего состояния мира.
Тут не надо писать 10 или 100 обработчиков... Есть обработчик для всех исключений...

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

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


Ясно.

Тут ты конечно же прав... про то что лучше не писать порченную информацию...
Но вариантов решений этой задачи много... у меня есть система дампа мира...
это когда состояние мира постоянно сохраняется в случае изменений...
после этого изменения фиксируются ... т.е. фиксируется состояние мира в
котором данные корректны.

Получается что в случае креша - потеряются только изменения с последней точки состояния
мира в дампе.

А эээ... если уж так хочется, то что мешает использовать СУБД с транзакциями и закрывать их в гарантированно стабильных состояниях ? Я долго все это жевал... кругами.... и к окончательному решению увы не пришел. Есть масса аргументов ЗА использование СУБД, и несколько против.... в частности - она ломается вся целиком, а 24х365 админа у нас нету, увы... нереально это. Что делать - неясно.

Я тоже долго ходил вокруг СУБД. И решил отказаться по разным причинам, в том числе и те, которые привел ты - ломается целиком, пришлось бы зависить от стороннего ПО, не факт что было бы быстрее собственного решения, сложнорасширяемое решение. При развитии движка пришлось бы городить новые таблицы и менять старые. СУБД рулит при сложных взаимосвязях, а в маде связи наооборот простые... список мобов, объектов, чаров, где находяться и что имеют...
это все... СУБД получался для меня слишком избыточным. Поэтому перешел к простому дампу мира - в постраничном файле, где мир пишется в бинарном формате. Этот дамп требуется только в случае сбоя в работе... При нормальном завершении - вся информация сохраняется в хмл, а дамп файл удаляется.

В принципе не вижу никаких проблем, кроме проблем с поддержкой.
С другой стороны... сломается и хрен с ним, пусть ломается. Утром приду и исправлю.
Это лучше, чем если будет потихоньку ломаться.... в процессе работы.

Основные плюсы - транзакции. Основные минусы - большая привязка к хостингу итп.
Скорость... трудно сказать, не думаю, что самописное будет заметно быстрее.

Тему о сериализации и СУБД решил перенести сюда...
http://forum.mudconnector.su/post410.html