Но очень быстро оказывается, что настоящая сложность не в самих задачах, а в инфраструктуре вокруг них.Сначала хочется просто запускать код в фоне. Потом появляются ретраи, таймауты, логирование, контроль выполнения. Ещё чуть позже всплывают совсем неприятные вопросы: что делать с пропущенными запусками после рестарта, как не дублировать задачи и где вообще должна жить логика планирования.В какой-то момент становится очевидно: Читать далее
Допустим, необходимо запустить множество фоновых задач в .Net с возможностью в дальнейшем обратиться к их состоянию. Это может быть полезно, если задача выполняется долго, а идентификаторы этих задач нужны пользователю в момент отправки запроса, для дальнейшего обращения к прогрессу выполнения этих потоков. Читать далее
Планировщик Linux долгое время оставался зоной, куда можно было заглянуть, но почти невозможно вмешаться без пересборки ядра. С появлением sched_ext эта граница сдвинулась: теперь логику планирования можно описывать кодом на C и загружать в ядро через eBPF. В статье разберём минимальный рабочий планировщик, посмотрим, как он взаимодействует с ядром, и обсудим, какие новые возможности это открывает для экспериментов и диагностики поведения системы под нагрузкой. Вникнуть в ядро
Недавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач.Когда основная…