Пока что код в порядке (за исключением того, что отставание в 1 кажется чрезмерно строгим), проблема, конечно же, возникает, когда вы пытаетесь accept
установить соединение на любом прослушивающем сокете, поскольку accept
обычно является блокирующим вызовом (и «опрос» при попытке принять с короткими тайм-аутами на любом из сокетов поочередно сожжет машинные циклы до бесполезной цели).
выберите , чтобы спасти! -) select.select
(или на более совершенных ОС select.poll
или даже select.epoll
или select.kqueue
... но, старый добрый select.select
работает везде! -) сообщит, какой сокет готов и когда, так что вы можете accept
соответственно. Кроме того, asyncore
и asynchat
обеспечивают немного больше организации (и сторонняя структура twisted
, конечно, добавляет lot с такой "асинхронной" функциональностью).
В качестве альтернативы, вы можете посвятить отдельные потоки обслуживанию двух сокетов прослушивания, но в этом случае, если функциональность разных сокетов должна влиять на одни и те же общие структуры данных, координация (блокировка и с) может стать щекотливой. Я бы, конечно, рекомендовал сначала попробовать асинхронный подход - он на самом деле проще, а также предлагает потенциал для значительно лучшей производительности! -)