|
|
|
Можно ли узнать из за какого потока было убито приложение?
|
|||
|---|---|---|---|
|
#18+
Akh onstat-Дабы приоткрыть дверь в темную комнату, опубликуй пожалуйста здесь вывод , который появится на экране после выполнения: Нет сейчас никакого приложения, которое падает. Излечил в течении суток с момента задания вопроса. Сейчас интересует подход/средства по поставленному вопросу. по этому? Akh Первый вариант, мне, как правило, удается предусматривать архитектурно и аналитически. Основная проблема - во втором варианте. Здесь причины бывают разные, вплоть до невнимательности и опечаток. Писать, же менеджер, выполняющий синхранизацию для последовательной работы, мне кажется слишком накладно. Тем более учитывая модульность архитектуры. Конкрентый ответ дать тяжело. Если в общем, то ИМХО при разработке модульной архитектуры, желательно предусмотреть возможность трассировки модулей по отдельности. И включения трассировки на лету путем посылки(обработки) сигналов (SIGUSR1 например). Помимо этого я имею привычку заводить класс исключений(иногда и иерархию) для отладочных целей и бросаться исключениями направо и налево если предвидится потенциально убойная ситуация. (Класс исключения содержит в себе помимо всего прочего номер строки и файл где, оно было инициировано). Таким образом вопросы неоднозначного поведения(трактования задачи) решаются с постановщиком или самостоятельно еще на этапе первых запусков программы(модуля). Где ловить эти исключения, зависит он контекста. НО самое главное, там будет известно место, откуда оно пришло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 18:42 |
|
||
|
Можно ли узнать из за какого потока было убито приложение?
|
|||
|---|---|---|---|
|
#18+
Akh A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять. Это трудоемкий процесс - раз. Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два. Я хочу знать какой поток совершил глупость. Потом совмещая с мессаджами, определять ошибку. А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока? а смысл? если каждый поток исполняет тот же код? что ето даст? У меня обычная схема - взаимодействие классов, некоторые из которых имеют свои потоки. Стековая архитектура (по типу TCP/IP). Код выполняется разный, и кто-то (поток) может спороть ерунду. Если опредилить, кто это сделал, будет проще начать искать ошибку (функцию, потом действие, потом анализ ситуации, а потом уже анализ причин). Не понимаю. Потоки разные, но ходят по одним и тем же функциям или нет. Если да, то нет смысла ловить. Вообще средствами скриптов не так уж сложно добавить в каждую функцию типа Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 19:05 |
|
||
|
Можно ли узнать из за какого потока было убито приложение?
|
|||
|---|---|---|---|
|
#18+
Резюме к моему последнему посту : [ b]Поддержка и развитие большого проекта всегда обходится дороже разработки версии 1.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2007, 19:17 |
|
||
|
Можно ли узнать из за какого потока было убито приложение?
|
|||
|---|---|---|---|
|
#18+
onstat-Если в общем, то ИМХО при разработке модульной архитектуры, желательно предусмотреть возможность трассировки модулей по отдельности. И включения трассировки на лету путем посылки(обработки) сигналов (SIGUSR1 например). Помимо этого я имею привычку заводить класс исключений(иногда и иерархию) для отладочных целей и бросаться исключениями направо и налево если предвидится потенциально убойная ситуация. (Класс исключения содержит в себе помимо всего прочего номер строки и файл где, оно было инициировано). Таким образом вопросы неоднозначного поведения(трактования задачи) решаются с постановщиком или самостоятельно еще на этапе первых запусков программы(модуля). Где ловить эти исключения, зависит он контекста. НО самое главное, там будет известно место, откуда оно пришло. 1. учту. спасибо. 2. Использую. Не всегда хватает. Особенно не зная, какой поток облажался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 10:06 |
|
||
|
Можно ли узнать из за какого потока было убито приложение?
|
|||
|---|---|---|---|
|
#18+
A. Fig Lee Akh У меня обычная схема - взаимодействие классов, некоторые из которых имеют свои потоки. Стековая архитектура (по типу TCP/IP). Код выполняется разный , и кто-то (поток) может спороть ерунду. Если опредилить, кто это сделал, будет проще начать искать ошибку (функцию, потом действие, потом анализ ситуации, а потом уже анализ причин). Не понимаю. Потоки разные, но ходят по одним и тем же функциям или нет. Если да, то нет смысла ловить. Вообще средствами скриптов не так уж сложно добавить в каждую функцию типа Код: plaintext 1. 2. 3. 1. Выделил жирным. 2. Была такая мысль, когда-то. Но средствами скриптов отказался. Сейчас использую в ручную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2007, 10:09 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=34317238&tid=2029477]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
79ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 247ms |
| total: | 446ms |

| 0 / 0 |
