дает полчаса-час бодрости и ясной головы. Потом спать 8)

вот пример

мне нужно обрабатывать все события в классе Server

Да для меня и кофе обычный - не особо хорошо. Потом сердце бывает чутка покалывает. Думал уже болячка какая - ан нет) Когда военком призывал сердце проверили - влепили а1

Значит все нормально

Пока что

мне нужно обрабатывать все события в классе Server

Передавать сервер аргументом в конструктор Device, чтобы там внутри self._server.handle(event)

т.е. колбеки городить?

хочется красиво сделать

и главное правильно

у меня с сердцем не все в порядке - Б1. Кофе пью редко. От кофе потом глаза нараспашку. Но с сердцем норм

это не коллбэк же, это хэндлер

"я хочу обрабатывать в сервере" - сделай в сервере метод хэндлер и вызывай его

но это все равно не правильно

сначала сделай

но тогда не нарушается ли принцип ООП?

чтобы работало

да не бойся

я уже сделал

и работает

но мне не нравится

а потом уже рефакторь так, чтобы было по ООП

супер

ну смотри

я попросил помощи а не рассказывать про этапы написания и отладки ПО

в threading есть event

это вполне нормальный dependency injectioon

событие должно обрабатываться в сервере, значит сервер является dependency для device

передавай его в конструкторе или выставляй сеттером

но он также будет и для всех остальных классов

получается что все знают про сервер

про класс

метод make_event у сервера считается "публичным", соответственно Device будет им пользоваться

а это не хорошо

Хотя, честно говоря, я не до конца уверен в честности военкомата. Моему другу (к слову, из таблицы для проверки зрения видит только первые две строчки) окулист влепил а1. Тут уж, как говориться: годен для ближнего боя нах)

все знают про то, что события обрабатываются не здесь, а кем-то еще

они не знают, что этот "кто-то еще" это один общий для всех сервер

но они знают, что этот "кто-то еще" приходит к ним аргументом и что у него есть метов make_event, который надо вызвать

кто нибудь сталкивался с такой проблемой?

ну хз

просто проект уже не маленький (порядка 10к строк)

и сделано как раз именно так

а это не хорошо

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

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

как ты предлагаешь

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

по логике разрабов threading, класс тебе особо не нужен

вот прямо сейчас в одном своем проекте эту мудрость выпиливаю

да и сам threading не нужен в большинстве задач

получается тривиально и красиво

по логике разрабов threading, класс тебе особо не нужен

например лок. Где-то я определяю локер queue_lock = threading.RLock(), а потом раздаю его всем остальным, и лочу нужные ресурсы с помощью этого локера

например лок. Где-то я определяю локер queue_lock = threading.RLock(), а потом раздаю его всем остальным, и лочу нужные ресурсы с помощью этого локера

давай с другой стороны зайдем. Зачем тебе треды вообще?

например лок. Где-то я определяю локер queue_lock = threading.RLock(), а потом раздаю его всем остальным, и лочу нужные ресурсы с помощью этого локера

похоже на извар какой то)

изврат

они занимаются своими задачами

давай с другой стороны зайдем. Зачем тебе треды вообще?

я посмотрел пример, там треды

я посмотрел пример, там треды

какую задачу ты хочешь решить?

давай с другой стороны зайдем. Зачем тебе треды вообще?

а лично в моей, уже решенной задаче, основное тело программы создает кучу тредов, которые делают свои задачи, результаты складывают в очередь, а другой тред разгребает эту очередь и складывает все в базу. Выходит быстрее, чем все это дело будет обрабатывать один поток. ЗЫ. афтар экземпла не я

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

Зачем threading?

а лично в моей, уже решенной задаче, основное тело программы создает кучу тредов, которые делают свои задачи, результаты складывают в очередь, а другой тред разгребает эту очередь и складывает все в базу. Выходит быстрее, чем все это дело будет обрабатывать один поток. ЗЫ. афтар экземпла не я

такие вещи в питоне тредами делать бессмысленно, ибо GIL

Зачем threading?

+

а лично в моей, уже решенной задаче, основное тело программы создает кучу тредов, которые делают свои задачи, результаты складывают в очередь, а другой тред разгребает эту очередь и складывает все в базу. Выходит быстрее, чем все это дело будет обрабатывать один поток. ЗЫ. афтар экземпла не я

то есть создается глобальная очередь, доступная всем классом, в которую они и складывают события?

ну то есть можно в качестве ресерча сделать такой проект

но быстрым он не будет

и эффективным тоже

ERROR: S client not available

В лучшем случае использование тредов не замедлит исполнение по сравнению с однопоточным вариантом. В худшем - будет медленнее чем в один поток

допустим убираем потоки и делаем все на асинхроне

вопрос все равно остался

как лучше всего передать события в основной класс

вопрос все равно остался

если у тебя асинхрон - в большинстве случаев очередь тебе не нужна

потому что у тебя уже есть генераторы

ты передаешь просто генератор в класс и он сам из него все достает

такие вещи в питоне тредами делать бессмысленно, ибо GIL

нет. Ибо время на обращение-ответ от некоего сервера в интернетах где-то 30 сек с учетом ошибок. Если каждый раз ждать ответ, то 2ляма запросов ты будешь две недели разгребать. А если создать 50 тредов, которые будут выполнять запрос, получать данные и складывать и для обработки. то на решение проблемы выйдет в разы меньше времени, ибо мы убираем самое узкое место.

нет. Ибо время на обращение-ответ от некоего сервера в интернетах где-то 30 сек с учетом ошибок. Если каждый раз ждать ответ, то 2ляма запросов ты будешь две недели разгребать. А если создать 50 тредов, которые будут выполнять запрос, получать данные и складывать и для обработки. то на решение проблемы выйдет в разы меньше времени, ибо мы убираем самое узкое место.

прочитай сообщение Романа выше

в питоне треды так не работают

в 3 вроде лучше дела с GIL

делать треды в надежде что-то ускорить - в 90% бессмысленно

нет. Ибо время на обращение-ответ от некоего сервера в интернетах где-то 30 сек с учетом ошибок. Если каждый раз ждать ответ, то 2ляма запросов ты будешь две недели разгребать. А если создать 50 тредов, которые будут выполнять запрос, получать данные и складывать и для обработки. то на решение проблемы выйдет в разы меньше времени, ибо мы убираем самое узкое место.

Тебе тем более треды не нужны

не нужно ускорять

в 3 вроде лучше дела с GIL

да, но тем не менее

он есть

нужно не усложнять

асинхрон хорош в скрипте на 150 строк

Как раз блокирующие запросы тредами ускоряются

нужно не усложнять

ну так что может быть проще одного потока и генератора? :)

Как раз блокирующие запросы тредами ускоряются

а у него все в сеть упирается?

или во что?

Как раз блокирующие запросы тредами ускоряются

Их всего несколько штук. Остальное покрывается o_nonblock

а у него все в сеть упирается?

в сеть

Ну судя по его сообщению, в сеть

в сеть

протокол какой?

http?

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

протокол какой?

http дергать приходится

протокол чего?)

И так мы легко выяснили, что человеку треды не нужны

делать треды в надежде что-то ускорить - в 90% бессмысленно

у меня видимо 10%, ибо оно ускорилось. А как сделать быстрее в один поток я хз. Треды я хоть как-то контролировать могу