ZZZ
Архитектурно такой приём мне не нравится. Не люблю:

“Не люблю” - это понятно. Но “архитектурно”…
В чем, по-твоему, может быть проблема?

nerijus
Много ли консольных програм которых нужно останавливать клавиатурой…

А речь идет не о ctrl+C(т е SIGINT). Он тут только для удобства отладки. Я же могу слать процессу любой другой сигнал - например SIGUSR1. Ведь общение с неким сервером логично строить сигналами. Вот о них и речь.

nerijus
А где у меня в примере ты видишь еще хотя бы один поток кроме main и worker? Для простоты я не делал никакого листа, пула и т.д. и не морочил этим себе голову.

Вот и мы упростили пример. На самом деле там кроме главного ещё два потока, которые тоже должны останавливаться.

nerijus
А есть ли альтернатива когда поток ждет, ничего не делает, но при этом может получить о обработать KeyboardInterrupt? Если есть выкладывайте, сам буду рад увидеть Если нет, тогда предложите более элегантное решение.

Использовать signal, как и было сделано изначально.

nerijus
Много ли консольных програм которых нужно останавливать клавиатурой…

Ну… Я часто что-нить останавливаю… :-)
А вообще Alex2ndr ответил, хотя в данном случае проблема приобрела более академический характер.

Lexander
“Не люблю” - это понятно. Но “архитектурно”…
В чем, по-твоему, может быть проблема?

Бесконечные, безусловные циклы, это сама по себе проблема. С виду всё просто, но на практике у меня были заглюки, когда я не мог отловить место зависания алгоритма. ИМХО, оно приемлемо, но если можно обойтись, то лучше обойтись.

ZZZ
Вот и мы упростили пример. На самом деле там кроме главного ещё два потока, которые тоже должны останавливаться.

Вообще не понял что ты этим хотел сказать. Напал на меня что в коде проблемы (которых реально нет), а потом даже непонятно за чем оправдываешься…

ZZZ
Использовать signal, как и было сделано изначально.

Про это уже обсуждали, join не будет прерван.

ZZZ
Бесконечные, безусловные циклы, это сама по себе проблема. С виду всё просто, но на практике у меня были заглюки, когда я не мог отловить место зависания алгоритма. ИМХО, оно приемлемо, но если можно обойтись, то лучше обойтись.

Хм, таких циклов в коде ядра полно. Все спинлоки на этом построены, которые очень часто в ядре используется. Ну и конечно этот цикл может быть прерван поскольку он в exception frame находится. Во вторых это простой концептуальный пример и глупо в нем искать всякие мелочи. Без цикла тут не обойтись, а уж каким образом из него вийти, это уже пусть каждый сам решает. Я критику уже услышал в прошлом посте, попросил предложить решение, а его все нет, только еще побольше критики :rolleyes:

nerijus
Напал на меня что в коде проблемы (которых реально нет), а потом даже непонятно за чем оправдываешься…

Эээ… Я не нападал… Вроде… Или просто злой стал и уже не замечаю? :-)

nerijus
Про это уже обсуждали, join не будет прерван.

Правильно. И поэтому мы пришли к велосипеду, но с другой стороны.

nerijus
Хм, таких циклов в коде ядра полно. Все спинлоки на этом построены, которые очень часто в ядре используется.

Само собой. Но когда это не мои циклы не в моём коде, то всегда пожалуйста. Я а стараюсь обходиться без них.

nerijus
Я критику уже услышал в прошлом посте, попросил предложить решение, а его все нет, только еще побольше критики

http://www.python.su/forum/viewtopic.php?pid=53095#p53095 и следующий пост Alex2ndr'а.
Собственно это и есть решение, которое нас, вроде как, устроило. Хотя и и согласен с тем, что твой вариант тоже имеет право на существование.