Есть список строк, в него строки потихоньку заносятся в основном цикле скрипта.
Нужно как-то сделать кучу потоков, которые по очереди будут брать строки из этого списка и обрабатывать. Причём если поток уже брал строку не позднее, чем 10 секунд назад, он должен пропустить свою очередь. То есть уже понятно, что каждый поток должен быть объектом и хранить у себя информацию о времени последнего вызова. И вот чем подобную многопоточность организовать я хз.

Что лучше подойдёт для этих целей? Нужна возможность действительно кучу таких потоков запилить и чтоб ни память не кончилась, ни процессор не расплавился. А при наследовании от threading.Thread и переопределении его метода run() происходит именно это. Буду очень признателен за подсказку.

Metallikus
ни процессор не расплавился

Если задача сложная он все равно расплавится, как ни выеживайся. Чего жадть 10 сек, кулер побольше поставьте, обычно железо не должно портиться от работы CPU на полной нагрузке.

Вроде бы greenlet - то, что нужно. Но чёт я не нахожу инфы как с ним в ООП стиле работать. Никому пример с наследованием от этого класса не попадался?

Очереди напрашиваются, модуль queue. Можете у меня в блоге посмотреть статейку и там примеры

Metallikus
Причём если поток уже брал строку не позднее, чем 10 секунд назад, он должен пропустить свою очередь.

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

py.user.next
Когда делаешь потоки, надо предполагать, что запускаться они будут в прямом порядке

Но у меня надо обрабатывать целую кучу строк, причём обработка предыдущей строки влияет на алгоритм обработки последующей внутри одного потока. И это влияние подразумевает, что обработка следующей строки ранее, чем через 10 секунд будет некорректной. То есть имеем ту же ситуацию, что и с высокой нагрузкой каждого потока, только в нормальной ситуации он всё это время занят и потому “пропускает” сваою очередь, а у меня тупо ждать должен. Если сделать через наследование от threading.Thread, переопределить там метод run и прописать после обоработки “time.sleep(10)”, то всё работало бы как надо, если бы не так сильно тормозило.

Metallikus
Но у меня надо обрабатывать целую кучу строк, причём обработка предыдущей строки влияет на алгоритм обработки последующей внутри одного потока.

Опиши конкретней само задание. Потому что вычисления секунд - это признак того, что ты просто неправильно пытаешься сделать что-то. Работа потоков не определена: первый поток может запуститься и завершиться либо первым, либо в середине, либо вообще после всех. И ты никак не предугадаешь. Тебе может казаться, что ты там правильно всё замерил, а оно будет работать вообще неожиданно.

Работаю с неким веб-сервисом, каждый поток - отдельный клиент со своим ключом. Если клиент слишком часто шлёт запросы, веб-сервис запрашивает капчу. Так что либо нейронную сеть пилить, либо не наглеть и добавлять паузы между запросами в каждом (микро)потоке.
Пока пытаюсь как-то gevent прикрутить для создания воркеров.

Metallikus
Если клиент слишком часто шлёт запросы, веб-сервис запрашивает капчу.

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

Очереди, это правильно. Посмотри на RabbitMQ.