В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

SPb Python

1314 membersпожаловаться на группу
2020 September 17

AN

Aleksey Nakoryakov in SPb Python
Даниил Козырев
Привет. А возможно ли сделать чтобы программа выполняла какую-нибудь функцию, потом когда человек что-то написал боту, то выполнение функции прекращается, отвечает там человеку и т.д. А после того как диалог закончился снова идти выполнять функцию?
К тому, что функция выполняется долго, но не хочется прерывать обмен сообщениями с пользователем?
источник
22:36пожаловаться#1

∀

∀lǝxǝʎ in SPb Python
Возник вопрос при изучении кода тулзы: а вот запускать 10-20-100 потоков (import threading) HTTPServer на одном сокете с SO_REUSEADDR это вообще норм? На сколько оно адекватно работает и производительно?
источник
23:04пожаловаться#2

SK

Sergio Keler in SPb Python
∀lǝxǝʎ
Возник вопрос при изучении кода тулзы: а вот запускать 10-20-100 потоков (import threading) HTTPServer на одном сокете с SO_REUSEADDR это вообще норм? На сколько оно адекватно работает и производительно?
Можешь потерять связность на обрывах связи и большом количестве time_wait.
Лучше бы aio...
источник
23:53пожаловаться#3
2020 September 18

p

pragus in SPb Python
∀lǝxǝʎ
Возник вопрос при изучении кода тулзы: а вот запускать 10-20-100 потоков (import threading) HTTPServer на одном сокете с SO_REUSEADDR это вообще норм? На сколько оно адекватно работает и производительно?
смысла нет, все равно одновременно работает только 1 поток.
источник
00:10пожаловаться#4

∀

∀lǝxǝʎ in SPb Python
pragus
смысла нет, все равно одновременно работает только 1 поток.
Почему? 🤔
источник
00:11пожаловаться#5

p

pragus in SPb Python
∀lǝxǝʎ
Почему? 🤔
потому что GIL.
источник
00:12пожаловаться#6

MK

Maxim Koltsov in SPb Python
Эх
источник
00:22пожаловаться#7

MK

Maxim Koltsov in SPb Python
Идут года
источник
00:22пожаловаться#8

MK

Maxim Koltsov in SPb Python
А проблемы те же...
источник
00:22пожаловаться#9

MK

Maxim Koltsov in SPb Python
И вопросы
источник
00:23пожаловаться#10

MK

Maxim Koltsov in SPb Python
Пора s/python/go/?
источник
00:23пожаловаться#11

∀

∀lǝxǝʎ in SPb Python
pragus
потому что GIL.
Но в случае http там много io операций с сокетом и данными на диске. Они же не лочатся?
источник
00:26пожаловаться#12

MK

Maxim Koltsov in SPb Python
лочатся
источник
00:26пожаловаться#13

∀

∀lǝxǝʎ in SPb Python
Maxim Koltsov
лочатся
Ещё раз повтыкал в статьи. Gil отпускается при входе в любое io
источник
00:46пожаловаться#14

II

Ilya Ilyinykh in SPb Python
∀lǝxǝʎ
Ещё раз повтыкал в статьи. Gil отпускается при входе в любое io
Блокировка потоков и GIL - это разные вещи.

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

Неблокирующий  ввод-вывод позволяет тебе переиспользовать потоки, а не ждать ими конца блокировки (так работает RxJava/Reactor), насколько я знаю в питоне асинхронность по-другому реализована. Но суть проблемы в этом.

Я думаю тут многие лучше меня разбираются, если я неправ - поправят.
источник
01:17пожаловаться#15

DA

Dmitry Alimov in SPb Python
Ilya Ilyinykh
Блокировка потоков и GIL - это разные вещи.

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

Неблокирующий  ввод-вывод позволяет тебе переиспользовать потоки, а не ждать ими конца блокировки (так работает RxJava/Reactor), насколько я знаю в питоне асинхронность по-другому реализована. Но суть проблемы в этом.

Я думаю тут многие лучше меня разбираются, если я неправ - поправят.
к сожалению в Python GIL как раз про блокировку потоков и они реально простаивают(
источник
01:19пожаловаться#16

DA

Dmitry Alimov in SPb Python
в итоге получаем что-то такое
источник
01:20пожаловаться#17

DA

Dmitry Alimov in SPb Python
источник
01:20пожаловаться#18

II

Ilya Ilyinykh in SPb Python
Dmitry Alimov
к сожалению в Python GIL как раз про блокировку потоков и они реально простаивают(
Да, я, наверное, не так сказал

Я хотел сказать, что ожидания ввода-вывода и ожидание GIL - это разные причины. Ну и да, из-за GIL в питоне даже если бы потоки не стояли в блокировке на io, они (кроме 1) бы все равно стояли потому что ждут GIL

Я бы кинул что почитать, но у меня под рукой просто нет ссылок 😔
источник
01:35пожаловаться#19

∀

∀lǝxǝʎ in SPb Python
Либо я таки что-то не дочитал, либо вы меня в чём-то не том пытаетесь убедить.
Gil приводит к тому что реально исполняется только один поток в один момент времени, но это с точки зрения строк кода, а вот если строка это io, то в этот момент gil отпускается и могут работать другие потоки.
Из того что я написал, кажется, что при достаточно большом количестве io операций в коде, threading становится полезным. Т.е. накладные расходы от переключений между потоками компенсируются отсутствием простоя при ожидании io.

Что не так в моих рассуждениях?
источник
06:15пожаловаться#20