Коллеги из enterprise-поддержки Microsoft постоянно сталкиваются с одной и той же проблемой: система зависает из-за драйверов, которые нарушают простое правило. Callback-функции процессов и потоков должны отрабатывать быстро и без блокировок. Документация прямо запрещает в этих callback'ах вызывать user-mode сервисы, обращаться к реестру, делать блокирующие вызовы или IPC, а также синхронизироваться с другими потоками — это ведёт к reentrancy deadlocks.
Казалось бы, всё ясно. Но находится хитрец, который решает обмануть систему. Он следует букве рекомендации «используйте System Worker Threads для тяжёлой работы» и передаёт задание рабочему потоку. А потом… блокируется в callback'е и ждёт, пока этот поток завершится. Формально правила не нарушены: «Не жди другие потоки» там не написано. Но по факту это чистой воды блокировка.
В 2020 году документацию наконец дополнили прямым запретом: если используешь System Worker Threads — не жди их завершения. Иначе весь смысл асинхронной очереди теряется. Но и до этого правило было очевидно: «Don’t synchronize with other threads» работает и для случая, когда ты синхронизируешься через событие, которое выставляет другой поток. Технически это та же синхронизация.
Коллега из поддержки называет такой подход отмазкой «это не я, это мой брат». Родители сказали не включать телевизор, а ты попросил брата — и вроде как ты не виноват. Но эффект тот же. В контрактах для таких случаев пишут «не разглашать и не способствовать разглашению», чтобы нельзя было сказать: «Я не разглашал, я просто дал данные Бобу, а уж он их слил».
Автор статьи предлагает переписать документацию начистоту: сразу сказать, что callback должен работать без блокировок, сложные задачи делай асинхронно через System Worker Threads, а потом уже перечислять, что именно считается блокировкой. И выделить отдельно: в callback вообще нельзя делать ничего из следующего списка — тогда никаких лазеек не останется.