IT-redneck

ааа, терь виден ваш скилл. понимаете в чём беда, в простейших случаях всё отлаживается и без этих костылей (да и серьёзных проблем быть то и не может), в нормальных случаях (ака пара сотен тредов), ваши гуёвые говнодебаггеры вам помогут так же как и поход в настоящую православнутую церковь.

PS. ну и справедливости ради - гдб (к коему есть отличная морда для емаксов) всё это умеет искаропки.

From:

denisioru.livejournal.com

Между простейшими случаями в один поток и "нормальными" в пары сотни - есть масса вещей, которые встречаются в реальной жизни, но явно отсутствуют в Вашем воображении ;)

From:

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

From:

denisioru.livejournal.com

ок, есть REST-сервис, который ждет изменения состояния неких приборов. Как правило, юзер одновременно мониторит до 10-20 приборов. В некоторых случаях есть условия, при которых изменения надо игнорировать. Условия мониторинга меняются юзером во время ожидания изменения состояний приборов. Хочется поставить контрольную точку и посмотреть ряд параметров в одном из потоков мониторинга, которые получаются при совпадении некоторых условий. А также знать, откуда ноги растут у условий.

From:

см. ответ на пост ниже.

From:

Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

Еще один вариант: когда для отладки логами нужно поставить вызовов этих логов десять штук, но на один раз - быстрее запустится под отладчиком.

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

From:

>Работа в одном потоке в гуишной проге с неебическими структурами данных. Их визуализировать в лог и потом анализировать заебешся, если честно. Это еще хорошо, когда у них встроенные методы дампа есть, но без этого - проще запустить в VS и посмотреть на значение переменной (оно из ее типа автоматом делает гуишный дампер хитрый).

если методов дампа нет - то у вас уже всё плохо и проект находися в большой яме с говном. у меня методы дампа есть _всегда_, я живу в паралельном мире.

>Еще один вариант: когда для отладки логами нужно поставить вызовов этих логов десять штук, но на один раз - быстрее запустится под отладчиком.

На один раз быстрее, на два быстрее, а на сотый уже будет медленее. Логирование, при должном опыте, пишется одновременно с основным кодом и опять же, как и методы дампа, есть всегда и сразу.

>И еще - если нужно отследить стек вызовов какого-то метода, а в рунтайме этот стек недоступен. Слава богу, в дотнете такого не бывает, а вот в дельфях и еще где-то - только отладчик, безальтернативно, стек вызовов в лог вывести невозможно.

Честно скажу, необходимость отслеживать стек вызовов возникала у меня всего несколько раз. Но для этого у меня уже было логирование вызова методов (с LOG_LEVEL_DEBUG) сразу ;]

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

From:

У меня в продакшене логов столько, что иногда клиенты плачут, просят сделать их round-robin, чтобы место не жрали. У меня не линукс, logrotate нету под руками к сожалению, хорошо хоть log4net сам ротатить умеет.

Ну вообще у вас все правильно написано. Тем не менее - стек вызовов нужен, безальтернативно. Сделать лог, по которому его можно восстановить - это пиздец, нужно логить вообще все, что выполняется.

From:

int foo(int bar, char *baz, huita *bee) {
  LOG(LOG_LEVEL_TRACE, "CALL: foo(%d, %s, %s)", bar, baz, huita_dump(bee));

не? пишется на полнлом автомате, тратятся на это секунды.

From:

Затем при рефакторинге меняются имена методов, списки параметров, и прочая. И вслед за ними - править все логи.
Кстати о huita_dump - строку возвращаемую кто удаляет?

From:

в стуктуре тупо есть char[xxx] __dump; в отладочном режиме - простейшее решение. есть эзотерические решения на диких макросах (выделение памяти специальным макросом, заносящим выделенный адрес в __dumps и освобождение "своих" строк в конце вызова LOG (написал лет так 8 назад, использую до сих пор).

From:

(загробным голосом)

а ещё для этого можно сделать в емаксе маленькую функу - тогда всего один хоткей будет тратиться (или вообще по вводу после объявления функи - о - ша допишу, а то лень было).

From:

>в нормальных случаях (ака пара сотен тредов)

Это нормальный случай только для индусов низшей касты. Пример однозначно плохого дизайна.

From:

буа-ха-ха. не - если вы хелловолы пишете, то да.

From:

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

From:

64 ядра например. оптимально при данной конкретной задачи 150 потоков, нет - распаралелить на несколько боксов не проще.

ещё возможен случай когда потоки большей частью в идле и таки да - они нужны.

From:

>случай когда потоки большей частью в идле и таки да - они нужны.

Вот так и получаются всякие Аутлуки, которые ничего не делают аж в 50 потоков.

From:

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

From:

Спасибо. Мне правда интересно увидеть задачу, где такое число потоков оправдано.

From: