Ничего не понял. но в треде отмечусь.

Я один по заголовку новости понял, что автор IBM_dW?

нет, я тоже. даже удивился что угадал

Аналогично.

Не один. Сразу заподозрил.

Кстати что-то знакомое. Подобной хернёй я в своей курсовой занимался.

> Не существует программ без ошибок

дальше не читал

Так эта технология полезна для случаев «когда всё хорошо» и «старые данные не нужны». Допустим, программа подвесит, клаву, крысу, ИК, блютуз, сеть - остальное работает нормально. Как перед или после перезагрузки посмотреть на логи если для их записи на диск нужен доступ к вышеперечисленным устройствам. Имхо, при хорошем кэшировании в озу и большом винте. файла вполне хватает, если конечно инфа не секретная.

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

Можно я переведу:

Не существует программ без ошибок

Мы неудачники

пользователи приложений могут столкнуться с неожиданными результатами в процессе выполнения программы

Работаем в Microsoft на досуге пишем СПО

программисты широко используют журналирование

Трусы используют педалирование

как использовать кольцевой буфер для эффективного журналирования в память вместо записи в файл

Масло масленое будем намазывать не на хлеб а на масло

Выбор соответствующего размера для буфера гарантирует

Бессмысленная игра слов

важные сообщения были сохранены и их можно будет использовать при отладке

неважные сообщения нужно отправлять в /dev/null

>Обычные функции, применяемые для отладки, такие как printf, write и другие, иногда могут изменять поведение программы в многопоточных приложениях, затрудняя отладку.

Отца демократии спасёт деление на ноль.

А тем временем Microsoft выпустила ролик, дискредитирующий OpenOffice.org http://www.youtube.com/watch?v=kzdykNa2IBU

> Имеются в виду конечно нормальные программы, а не хелловрлды.

ничего не меняющее уточнение

> А тем временем Microsoft выпустила ролик

черный троллинг :D

Обратите внимание на запрещённые комментарии и количество likes/dislikes.

Ты сам то понял, про что статья?

Масло масленое будем намазывать не на хлеб а на масло

Что не так?

Бессмысленная игра слов

Нет, не бессмысленная.

неважные сообщения нужно отправлять в /dev/null

Там им и место.

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

А ты не воспринимай фразу «Не существует программ без ошибок» буквально. Просто немного неформальный стиль.

> Ты сам то понял, про что статья?

Не читал но осуждаю.

А оказалось что вывод логов тормозит

Ну будь поаккуратнее.

>Не читал но осуждаю.

Я и не сомневался, тут на ЛОРе сплошные чукчи-писатели.

> Я и не сомневался, тут на ЛОРе сплошные чукчи-писатели

Ты это поосторожней, у меня тоже говна в запасе полно.

Блин, это же очевидно. Даже мне стыдно хвастаться, что я понял.

Зачем вы храните говно? Вы копрофил?

> Зачем вы храните говно? Вы копрофил?

говнофил скорее

Это синонимы. Только копрофил - общепринятое название этого понятия. А почему вы так поздно сидите на ЛОРе? Вы уже сделали уроки на завтра, молодой человек?

Совсем забыл, всё пошел делать. Спасибо что напомнили. :D

logrotate спасёт их. Шутка. Статья слабенькая как обычно. Чего ещё ждать от индуса который «имеет степень бакалавра в области химии, полученную в Индийском технологическом институте».

Кстати, буфер там не кольцевой, там кольцевой список. Хотя это больше вопрос того на какой уровень абстрагироваться....

анонимусы

В общем как всегда ЛОР не смог осилить смысл статьи.

Потому что отродясь ничего с тредами на С не дебагерели, когда оно раз в полчаса примерно падает, а если добавить printf() в косольку то это как-то синхронизирует треды и уже оно не падает.

В статье об этом ни слова, не думаю что тот индус что-то в этом понимает и что именно это он хотел сказать.

printf не синхронизирует, он просто код тормозит и это решает проблемы с доступом к общему ресурсу.

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

>Мы неудачники

Ну ты понел

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

Для автора программы, не владеющего асмой, вполне может заменить) Только зачем для этого такую хрень городить? Лучше использовать файл на виртуальной ФС висящей в ОЗУ. А для ошибок возникающих при первом выполнении фрагмента кода, педалит A=A/(A-A); Оно сработает и там, где есть сомнения в дееспособности процедур. Заодно и узнаешь, а выполняется ли оно вообще.

>А тем временем Microsoft выпустила ролик, дискредитирующий OpenOffice.org http://www.youtube.com/watch?v=kzdykNa2IBU

Ну вообще-то там всё по делу. ООо — тихий ужас.

> Потому что отродясь ничего с тредами на С не дебагерели, когда оно

раз в полчаса примерно падает, а если добавить printf() в косольку то

это как-то синхронизирует треды и уже оно не падает.

а если заменить «Нити» на «Процессы».. (а общие-объекты-нитей — заменить на общие «Каналы» ).. [и при этом использовать неблокирующие API, вместо {блокирующего+Нити} ] то тоже перестаётся падать?

....хм... какже быть.....(?)(?)(?) :-)
ведь нада же обязательно кушать кактус (нити) , а оно вот так скверно работает.....

> printf не синхронизирует, он просто код тормозит и это решает проблемы с доступом к общему ресурсу.

printf тут для простоты привели. Ясное дело что пишется в лог, а не в stdout. И в многопоточной программе естественно обращения к логу синхронизированы, иначе лог потом не прочесть. Так вот эта синхронизация и делает при достаточно высоком уровне логгирования исполнение последовательным :)

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

Опыта маловато наверное, поэтому и сомневаетесь. Дебаггер хорош когда знаешь, где проблема. Когда ещё не знаешь - кроме логов ничего не спасёт.

Мое скромное мнение.

1. Если используется буфер с тупой синхронизацией на каждый чих, то это может привезти к ликвидации искомых гонок.

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

3. Если вы легко поняли статью (в переводном варианте), то вы можете найти гонки методом пристального вглядывания в код.

> Так вот эта синхронизация и делает при достаточно высоком уровне логгирования исполнение последовательным :)

Вот интересно, если у меня, допустим, сообщения кидаются через Posix / SysV MQ потоку журналирования, это насколько упорядочивает исполнение?

> Ну вообще-то там всё по делу. ООо — тихий ужас.

с появлением LibreOffice — даже както интересно стало — когож в своих «рекламах» Ms теперь будет критиковать(?): OOo или LO %) %) :-D

Чем он от ООо отличается (будет отличаться)?

> Чем он от ООо отличается (будет отличаться)?

а ещё я хочу узнать кто станет призедентом мира в 2021 году :-)

феерический ппц. теперь понятно почему в IBM все такое большое и тормозное. учитесь у троллей Qt4

Этому треду место в девелопменте. Это не новость по сути. Не стоит в новостях пиарить свои статьи.

> Вот интересно, если у меня, допустим, сообщения кидаются через Posix /SysV ...

Это всего-навсего обозначает что у ваших разработчиков не все дома. Тестики погоняйте, быстрее UNIX stream сокетов ничего нет. А за sndmsg вообще убивать надо. Не упорядочивает никак. Сам вопрос об упорядочивании некорректен. При отсылке/приёмке сообщения ваш программный поток, не важно thread или proc, становится ядром в ряд таких же ожидающих в неопределённом порядке. Политика выбора активируемого в общем случае случайна. Что printf, что write, что sendmsg разница в длительности пути от логики программы к системному вызову. Эта разница конечно изменяет временные характеристики процесса. Боятся этого не нужно. Ну исправите другой дефект - всё равно он же был и нуждался в исправлении. А вообще нужно код читать, а не дебажить. Понимание системы в целом вот настоящая цель и основа любых улучшений.

Для начала поставить GNU/Linux. Потом можно не запускать программу под пользователем которому можно опускать интерфейсы. Потом можно добавить при остановке системы сброс накопленного на винт/флеш. Потом, в конце концов, логировать можно удалённо.

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

Возьмите прямой lockless ring buffer, сейчас как раз в ядре такой доделывают.

Насколько я могу судить lockless технология основана на добровольном самоограничении и самоконтроле, а теперь прикиньте последствия сбоя памяти/выхода за предел массива в такой системе. Для устранения потенциала сбоя системы логирования можно вынести логику логгера в отдельный процесс, но тогда возникает вопрос: а почему бы не вести логи сразу в сеть?

Я вообще больше склоняюсь к специализированной FS где файл зацикливается самим драйвером. А где физически эта FS будет засполагаться уже дело администратора.

Опыта маловато наверное, поэтому и сомневаетесь. Дебаггер хорош когда знаешь, где проблема. Когда ещё не знаешь - кроме логов ничего не спасёт.

Да, я редко использую треды(и те в питоне :)), но если речь идёт о поиске мест где конкурентный доступ мешает то начать стоит с предназначенных для этого утилит(дебаггер для примера привёл, не знаю как эти все тулзы для дебага тредовых апликух называются), большие логи можно до упячки парсить и вставлять их придётся на каждый чих. И, кстати, утверждение что нам нужны только последние куски логов нифига не верное :). И каким образом логи, например, помогут при отлавливании проблем с памятью? А valgrind-ом запросто.

|а если приложение в продакшне крутится но сыпится, тоже дебагер? :)

А тем временем Microsoft выпустила ролик, дискредитирующий OpenOffice.org http://www.youtube.com/watch?v=kzdykNa2IBU

Не зря там комменты запрещены:

Скольким людям понравилось 450

Скольким людям не понравилось 4787

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