потоки

[CPP11]

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

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

[Alexu007]

Так вот, при 2 и более отправителях последовательность НЕ "именно та".

"кто успел тот и съел"

От решаемой задачи зависит. Почему бы в сообщения не вставить порядковые номера, а получатель пусть решает, как поступать с сообщениями - сразу обрабатывать или сбросить в буфер и пусть ждёт очереди? Но если будет много инфы в очереди - то может здесь вообще потоки лучше не использовать? Сложный алгоритм работы с очередью сообщений съест эффект быстродействия потоков.

[Johnik]

От решаемой задачи зависит. Почему бы в сообщения не вставить порядковые номера, а получатель пусть решает, как поступать с сообщениями - сразу обрабатывать или сбросить в буфер и пусть ждёт очереди? Но если будет много инфы в очереди - то может здесь вообще потоки лучше не использовать? Сложный алгоритм работы с очередью сообщений съест эффект быстродействия потоков.

О каких сообщениях и очередях идет речь? CPP11 в начале говорил об механизме сигналов/слотов. Сигналы попадают в очередь сообщений Qt, и именно Qt распределяет их по потокам.

[Igors]

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

А Вы можете подтвердить Ваши слова кодом? (хотя бы псевдокодом)

Код

C++ (Qt)
thread->quit();
if(thread->wait(1000))
{
	delete worker;
	delete thread;
}
else {
...  // и что здесь??
}
 

[CPP11]

Igors, это зависит от контекста. Часто нужно сохранить промежуточное состояние приложения и после перезапуска попытаться вернуть его в это состояние. Естественно нужно зафиксировать сам факт падения и информацию, которая может помочь выявить причину - обычно это дамп процесса(чаще минидамп + состояние объектов), если программа полагается на сторонние компоненты, то имеет смысл сохранить и информацию о них. После перезапуска приносим извинения пользователю и отправляем себе отчёт об ошибке (некоторые приложения просят пользователя подтвердить отправку, т.к. в таких дампах может содержаться приватная информация).

[Igors]

Igors, это зависит от контекста. Часто нужно сохранить промежуточное состояние ...

Ну и что Вы будете сохранять в данном случае? Откуда Вы возьмете промежуточное состояние - или вообще хоть какую-то информацию достойную сохранения/посылки? И почему такая ситуация вообще расценивается как "падение"? Нитка не завершилась через 1 секунду? Так что с того, такое вполне вполне возможно если напр было распределено гораздо больше памяти чем физически имеет хилая машина, или хороший файл мапнут в память (вындоуз пошла по свопам).

Так зачем врать самому себе надеясь что ну когда-то (в будущем) Вы напишете тонну кода для обработки этой ситуации? В лучшем случае это будет assert который потом уберут. Здесь нет конструктивного выбора, и это лучше признать сразу.

[CPP11]

Ну и что Вы будете сохранять в данном случае?

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

Нитка не завершилась через 1 секунду?

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