Как человек, для которого упомянутые вращения никогда не представляли сложности, и которому они даже нравятся, я бы предпочел, чтобы везде одними только деревьями и ограничивались.
Хотелось бы, конечно, сказать, что в такие направления просто не стоит идти работать. Тогда в них станет меньше специалистов и средний спрос на 1 специалиста вырастет, что должно улучшить его положение.
В качестве примера задачи, которая должна вызвать взрыв энтузиазма у "А-сотрудников", предлагается построение системы автоматической цензуры. Надеюсь, будущие звезды прочтут это прежде, чем туда устраиваться, и не совершат ошибки. Карфаген должен быть разрушен.
Над сайтом им, конечно, еще работать и работать. Капча сломана, еще не все обязательные поля помечены как обязательные, из-за чего форма тупо не отправляется без объяснения причин.
Обратите внимание, асинхронный логгер ни на миллисекунду не задержит работу нашего приложения в целом. Он будет использовать паузы, пока мы ожидаем запроса от пользователя или ответа от внешнего сервиса.
That’s why logging to files is NOT truly async. aiologger implementation of file logging uses aiofiles, which uses a Thread Pool to write the data. Keep this in mind when using aiologger for file logging.
То есть ваша трактовка не корректна. В данном случае под-капотом используется тред-пул, а это значит, что он не ждет пауз, а вытесняет прочий код.
Попутно он порождает оверхед на поддержание тред-пула, а также лишает программу гарантии, что логи точно запишутся (например если электричество отключится, пока записывается лог) прежде, чем она продолжит выполняться. Я не говорю, что все это плохо, просто стоит это более явно проговаривать, а не преподносить как однозначно "лучшее" решение.
Выбор именно sqlite в качестве СУБД для проекта на асинхронном фреймворке тоже, честно говоря, странный. Дело в том, что sqlite - это файловая СУБД, а значит сталкивается с теми же ограничениями системных вызовов, что не позволяют сделать действительно асинхронной работу с файлами в aiologger. О чем нам авторы также честно пишут на странице проекта:
aiosqlite allows interaction with SQLite databases on the main AsyncIO event loop without blocking execution of other coroutines while waiting for queries or data fetches. It does this by using a single, shared thread per connection. This thread executes all actions within a shared request queue to prevent overlapping actions.
На шагах с #0 по #4 автор пытается рассказать про структуру бекенда, после чего внезапно перескакивает на фронтенд. По итогу нас ждет невнятная попытка все это обобщить, нелепая, как и весь js - автор будто бы пытается сложить число со строкой. Сверху все засыпано толстым слоем терминов, вероятно, для маскировки.
Насколько я знаю, WFG используются в т.ч. и на уровне OS, для разного рода ресурсов.
Про задержки согласен, но в чем здесь собственно отличие от моего поинта про производительность? Она да, проседает, потоки начинают больше ждать. Однако я не вижу, как это аффектит собственно семантику программы. Крайне нежелательно писать программу, как-то закладываясь на продолжительность этих задержек, и учитывая их в коде. А иного влияния, кроме как на продолжительность этих задержек, я не вижу.
Я видел реализации WFG в других языках, плюс этот подход активно используется в сложных многопоточных системах типа СУБД. Так что, мне кажется, причина отсутствия реализации на Python за 30 лет заключается в чем-то другом. Моя гипотеза: из-за ограничений интерпретатора питонисты крайне редко используют многопоточность, и в среднем понимают ее хуже, чем программисты на других языках. Поэтому некоторые элементы инфраструктуры находятся просто в зачаточном состоянии.
1. SmartLock не задает порядок, в котором его берут потоки, он лишь сохраняет его. Пока один поток берет блокировку, остальные, которые тоже хотели взять или отпустить любую другую блокировку, подвисают. Однако тот порядок, в котором они подвисли и потом выйдут из глобальной блокировки, остается нетронутым.
2. Многопоточные программы обычно пишутся с учетом, что другие потоки относительно данного могут выполнять свои задачи в любом порядке, если только мы не решим их дополнительно синхронизировать. Любой спонтанный порядок в соседних потоках, даже если он каким-то чудом возникнет (а не должен), входит во множество "любой порядок", а значит не должен оказаться неожиданностью. Он будет эквивалентен редкой флуктуации в поведении других потоков, то есть является в принципе ожидаемым поведением.
К слову, в CPython используется GIL — очень похожая сущность. На семантику многопоточного программирования она практически никак не влияет, только на производительность.
Как человек, для которого упомянутые вращения никогда не представляли сложности, и которому они даже нравятся, я бы предпочел, чтобы везде одними только деревьями и ограничивались.
Современные айпады вроде тоже 400 с чем-то г.
Кто-то кого-то или чего-то использовал, но я так и не понял, кто, кого или чего.
Рыночная экономика сама себя убивает. Именно таким способом, приходя рано или поздно к монополиям.
А есть что-то похожее на tabnine, но чтобы бесплатно?
Блокчейн не обязательно должен быть децентрализован.
Наконец-то я могу купить клон малины за 10 баксов всего за 26 баксов.
Хотелось бы, конечно, сказать, что в такие направления просто не стоит идти работать. Тогда в них станет меньше специалистов и средний спрос на 1 специалиста вырастет, что должно улучшить его положение.
В качестве примера задачи, которая должна вызвать взрыв энтузиазма у "А-сотрудников", предлагается построение системы автоматической цензуры. Надеюсь, будущие звезды прочтут это прежде, чем туда устраиваться, и не совершат ошибки. Карфаген должен быть разрушен.
Ничего не останется, скорее всего. Технологическая сложность обычно обратна времени жизни артефактов.
Над сайтом им, конечно, еще работать и работать. Капча сломана, еще не все обязательные поля помечены как обязательные, из-за чего форма тупо не отправляется без объяснения причин.
А в чем интерес для читателей хабра? Заходить на рандомный сайт в интернете, чтобы дать вам обратную связь, чтобы что?
Кринж (Cringe).
А теперь идем в документацию aiologger и читаем:
То есть ваша трактовка не корректна. В данном случае под-капотом используется тред-пул, а это значит, что он не ждет пауз, а вытесняет прочий код.
Попутно он порождает оверхед на поддержание тред-пула, а также лишает программу гарантии, что логи точно запишутся (например если электричество отключится, пока записывается лог) прежде, чем она продолжит выполняться. Я не говорю, что все это плохо, просто стоит это более явно проговаривать, а не преподносить как однозначно "лучшее" решение.
Выбор именно sqlite в качестве СУБД для проекта на асинхронном фреймворке тоже, честно говоря, странный. Дело в том, что sqlite - это файловая СУБД, а значит сталкивается с теми же ограничениями системных вызовов, что не позволяют сделать действительно асинхронной работу с файлами в aiologger. О чем нам авторы также честно пишут на странице проекта:
На шагах с #0 по #4 автор пытается рассказать про структуру бекенда, после чего внезапно перескакивает на фронтенд. По итогу нас ждет невнятная попытка все это обобщить, нелепая, как и весь js - автор будто бы пытается сложить число со строкой. Сверху все засыпано толстым слоем терминов, вероятно, для маскировки.
Не, тут не подскажу, к сожалению.
Согласен, за пределами мьютексов есть еще куча способов словить дедлок. Я бы в ваш список добавил еще дедлоки в распределенных системах.
Если вдруг решите написать об этом статью - я бы почитал с удовольствием.
Насколько я знаю, WFG используются в т.ч. и на уровне OS, для разного рода ресурсов.
Про задержки согласен, но в чем здесь собственно отличие от моего поинта про производительность? Она да, проседает, потоки начинают больше ждать. Однако я не вижу, как это аффектит собственно семантику программы. Крайне нежелательно писать программу, как-то закладываясь на продолжительность этих задержек, и учитывая их в коде. А иного влияния, кроме как на продолжительность этих задержек, я не вижу.
Я видел реализации WFG в других языках, плюс этот подход активно используется в сложных многопоточных системах типа СУБД. Так что, мне кажется, причина отсутствия реализации на Python за 30 лет заключается в чем-то другом. Моя гипотеза: из-за ограничений интерпретатора питонисты крайне редко используют многопоточность, и в среднем понимают ее хуже, чем программисты на других языках. Поэтому некоторые элементы инфраструктуры находятся просто в зачаточном состоянии.
Значимо влиять не должно.
1. SmartLock не задает порядок, в котором его берут потоки, он лишь сохраняет его. Пока один поток берет блокировку, остальные, которые тоже хотели взять или отпустить любую другую блокировку, подвисают. Однако тот порядок, в котором они подвисли и потом выйдут из глобальной блокировки, остается нетронутым.
2. Многопоточные программы обычно пишутся с учетом, что другие потоки относительно данного могут выполнять свои задачи в любом порядке, если только мы не решим их дополнительно синхронизировать. Любой спонтанный порядок в соседних потоках, даже если он каким-то чудом возникнет (а не должен), входит во множество "любой порядок", а значит не должен оказаться неожиданностью. Он будет эквивалентен редкой флуктуации в поведении других потоков, то есть является в принципе ожидаемым поведением.
К слову, в CPython используется GIL — очень похожая сущность. На семантику многопоточного программирования она практически никак не влияет, только на производительность.