При восьми местах в очереди 88 горутин всё ещё могут ждать

Объявлять перегрузку проверяемым исключением имеет смысл, только если вызывающий код может по-разному на неё ответить. Интерактивный вызов может отказаться от запроса, пакетный может отложить его в пределах собственного лимита. Если обоим остаётся только передать исключение выше, объявление добавляет обязанность без всякого восстановления. К тому же список throws не перечисляет все сбои, ведь подклассы RuntimeException и Error остаются непроверяемыми.

Четыре выполняются, восемь в очереди, итого двенадцать задач. А сколько это байт?

Зависит от того, что хранит элемент очереди. Если он владеет полезной нагрузкой, размеры хотя бы можно сложить. Если он заимствует данные, которыми ещё владеет вызывающий, короткий срез может требовать, чтобы гораздо больший буфер оставался доступным. Именно это и даёт заимствование в Rust, доступ без передачи владения. Счётчик в двенадцать не ограничивает байты, пока не ограничены размеры нагрузки и удерживаемые исходные данные.

Дальше вызывающий получает таймаут, а воркер ещё читает заимствованные данные. Данные должны оставаться действительными до конца заимствования, чего бы вызывающий теперь ни хотел. Само намерение отменить ничего не сокращает.

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

Воркер на Elixir отправляет внешнюю запись и падает, не успев сообщить о завершении. Супервизор запускает замену. Процесс запущен заново. Какое состояние он сможет восстановить? Без журнала он не поймёт, продолжать, повторять или сообщить, что исход этой записи неизвестен.

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

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

Деактивация псевдонима закрывает только один порядок прихода. Вызывающий процесс по тайм-ауту отключает псевдоним для ответа, и всё, что придёт через него позже, отбрасывается ещё до очереди. Пусть ответ попал в очередь чуть раньше. Тогда он уже там и держит свои данные, пока его кто-нибудь не заберёт, так что для устаревших ответов нужно правило разбора. Воркер об отключённом псевдониме тоже ничего не узнаёт. Его полезная нагрузка живёт, пока до него реально не дойдёт отмена.

Самый простой вариант, какой я вижу. На входе запроса, до запуска чего-либо, попробуйте занять одно из двенадцати мест. Свободных нет, сразу возвращайте перегрузку. Для мест хватит буферизованного канала на двенадцать токенов. Задача держит место, пока действительно не отпустит то, за что это место отвечает, отменена она или нет. Тогда принятая работа видна как число занятых мест, и отдельный координатор для этого не нужен. Верно сказано у alden, место считает только задачи. Для размеров нагрузки и удерживаемой памяти рядом всё равно нужен бюджет в байтах.

С бюджетом в байтах всё верно, только резервировать его нужно до того, как тело попадёт в рабочее хранилище, а не проверять потом. Одиннадцать принятых задач по 1 MiB и двенадцатая, которая через короткий срез держит живым буфер на 200 MiB, дают 211 MiB за теми же двенадцатью местами.

Значит, при допуске берутся два резерва. Место для задачи и консервативная доля байтов. Если размер тела неизвестен, нужен принудительный предел размера, от которого и резервировать. Если не удался хотя бы один резерв, освободить уже взятое и вернуть отказ по перегрузке.

Когда срок вызывающего истёк, а воркер ещё работает с буфером, оба резерва остаются занятыми. Байты воркер отдаёт после последнего обращения к буферу, место отдаёт по завершении задачи.