Логирование (logging) – это ведение записей(как правило сохранение в файл) в хронологическом порядке.
Ведение логов зачастую очень удобная, облегчающая жизнь разработчику, штука, а для больших серьёзных проектов это вообще неотъемлемая вещь.
Логирование помогает как на этапе отладки, так и на этапе внедрения, например я прицеплял утилиту к проектам, которая отправляла файл лога куда мне удобно(сайт, мыло, сервер), таким образом избегал процесса вымогательства у пользователя лог-файла.
Я использую логирование почти во всех своих проектах от средне до велика.
В этой статье я рассмотрю свою реализацию модуля ведения логов, которым пользуюсь и время от времени грейжу его.
Данный модуль можно так же применять в многопоточных приложениях.
Ведение логов зачастую очень удобная, облегчающая жизнь разработчику, штука, а для больших серьёзных проектов это вообще неотъемлемая вещь.
Логирование помогает как на этапе отладки, так и на этапе внедрения, например я прицеплял утилиту к проектам, которая отправляла файл лога куда мне удобно(сайт, мыло, сервер), таким образом избегал процесса вымогательства у пользователя лог-файла.
Я использую логирование почти во всех своих проектах от средне до велика.
В этой статье я рассмотрю свою реализацию модуля ведения логов, которым пользуюсь и время от времени грейжу его.
Данный модуль можно так же применять в многопоточных приложениях.
Разглядывал минут 5-7. Хорошо. Немного мудрено, особенно коллбэки, никогда подобное не использовал — не видел нужды.
ОтветитьУдалитьНо:
Открываешь файл на запись каждый раз — безопасно, конечно, если прога упадет, то все, что логгер записал будет в файле. Но производительность, особенно постоянное обращение к жесткому диску, удручает.
Не очень разбираюсь пока еще в потоках, поэтому гипотетический вопрос — если прога упадет в критической секции, обратившись перед этим в лог, имеем крах лога (ни новой записи, а также вероятность потери старых, файл-то открыт на r/w)?
1) Задержка была при следующем опыте: в цикле for создавались 500 потоков и каждую 2-ю мс писали лог, при этом после закрытия программы через несколько секунд OS ждала все очереди критических секций(несколько 10-ов секунд), закрывала потоки и файл лога весил десятки МБайт. При записи лога каждую секунду теми же потоками никакой задержки уже небыло, а т.е. запись идёт около 1-2 мс.(данные могут быть не точны - давно проверял)
УдалитьПоэтому с производительностью проблемы совсем не тревожили.
2) Прога не может упасть в КС, т.к. если что-то падает в это время, то это может быть только другой поток, а данный поток сначало завершит операцию записи(т.к. он ей занят) и гденить стопорнётся из-за сторонней ошибки(если так ему суждено). Максимум что может случиться в КС записи - это исключительные ситуации по записи в файл, что обработается try'ем и выдаст ошибку в каллбэк и покажется юзеру в realTimeLog, если такой имеется. Я специально для этого заюзал максимально атомарные WinAPI функи для записи.
ВОзможно ошибка VCL при каллбэке, но для этого у меня и разграничены операции каллбэка и записи в разные try'и, при такой ошибке файл даже не тронется, а просто закроется.
Тэкс, я верно понял, что критическая секция fcs защищает от вызова процедуры логирования из разных потоков одновременно? (еще раз повторюсь, все никак потоки не осилю, чтобы сесть и что-нибудь запрогить, поэтому глупые вопросы задаю).
УдалитьЕще раз просмотрел код, теперь уже с похмелья — продумано неплохо. Перепишу свой логгер с учетом особенностей твоего, наверное :)
Да, верно. Если убрать CS, то при одновременной записи в лог строки в файле будут сидеть друг на друге или совсем перетираться, например: "[лог1]: эта запись первого по[лог2]: а это совсем уже другая запись другого потока!", таким образом из 100 записей лога разными потоками в файле может оказаться 4-5 строчек(записей) лога)
УдалитьА так же в CS вызывается каллбэк, таким образом обеспечивается синхронизация обращения к VCL например(если такое есть в каллбэке конечно).
Рад, что тебе пригодилось)