Прийняла повну сувору паралельність Swift 6 без акторів, перекинувши місток від блокувального циклу подій C до головного актора через одного виробника, одного споживача й один порядок — після встановлення, що задача на подію губить порядок, від якого залежить інтерфейс.
Роботу виконано: вересень 2026
сувора конкурентність з одним порядком і без акторів
Ситуація. Повна сувора перевірка паралельності у Swift 6 перетворює гонитви за даними на помилки компіляції замість переривчастих аварій. Впроваджувати її проти бібліотеки на C — саме там, де стає важко: цикл подій ядра є блокувальним викликом, що має вічно виконуватися поза головним потоком, а значення, які він повертає, є вказівниками без жодних гарантій щодо паралельності. Компілятор не може міркувати про це все й відхилятиме всі, доки межу не буде описано явно.
Завдання. Повну перевірку треба було ввімкнути без жодних запасних лазівок, а це означало спроєктувати перехід від блокувального циклу на C до головного актора, а не обставляти його анотаціями.
Дія. Очевидним підходом є актор на підсистему, і його відкинули за вимірюванням, а не за смаком. Породження задачі на кожну вхідну подію дозволяє середовищу виконання планувати їх у будь‑якому порядку, а потік подій ядра є впорядкованим — подія «повідомлення змінено», що обганяє подію «повідомлення створено», на яку вона посилається, дає інтерфейс, що показує редагування чогось, чого ще не існує. Повторний вхід в актора робить це гіршим, а не кращим, бо актор може призупинитися посеред методу й обробити інший виклик. Те, що це замінило, є навмисно простим: один потік‑виробник, що володіє блокувальним циклом, один споживач, одна черга між ними та єдиний стрибок на головного актора наприкінці. Порядок зберігається, бо шлях рівно один і ніщо нічого не обганяє. Небезпечні типи, що перетинають цю межу, загорнуто в типи, чию потокобезпеку стверджують на обгортці, а не припускають, і твердження задокументовано разом із тим, чому воно чинне: вказівником володіє один потік, і його копіюють, перш ніж передати.
Результат. Програма компілюється за повної суворої перевірки паралельності без придушень, а впорядкованість подій є структурною властивістю, а не сподіванням. Ціною є те, що задум менш паралельний, ніж міг би бути: усе стікається через одного споживача, і якщо той споживач колись стане вузьким місцем, виправлення вимагатиме заново вивести, які події можна безпечно переставляти, а це саме той аналіз, якого це дозволило уникнути.
Погляньте назад на Спинила застосунок, що наповнював пам'ять зі швидкістю 41 МБ за секунду — зафіксовані 111 ГБ стиснених сторінок на машині з 36 ГБ, — обмеживши кожен потік подій, підписуючись за типом події та поклавши бюджет швидкості на журналювання, що звело 610 996 рядків журналу до 1 411. Читати далі: Написала парсер, який читає справжній C‑заголовок на 7 308 рядків і перевіряє кожне місце виклику, кожну константу переліку й те, що кожен клас‑власник вказівника є final, після того як рукописний заголовок‑заглушка дозволив викликам до трьох вилучених функцій скомпілюватися, злінкуватися й впасти. Або перегляньте повне портфоліо.
Одна частина довшого переліку — і він увесь на цьому сайті.
Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.