Що було б найкращим способом обробляти помилки в паралельних програмах?

Якщо паралельні алгоритми стукають у двері, можливо, вдалий час подумати про обробку помилок.

Тож спочатку були коди помилок. Ті смоктали. Можна було їх ігнорувати, тож ви могли пізно вийти з ладу та створити важкий для налагодження код.

Потім прийшли винятки. Після їх виникнення було неможливо ігнорувати, і більшість людей (крім Джоеля) їм подобаються більше.

І ось ми отримали бібліотеки, які допомагають паралельному коду. Проблема полягає в тому, що ви не можете обробляти винятки з паралельного коду так легко, як ви могли з непаралельним кодом. Якщо ви асинхронно запускаєте завдання, і воно викидає виняток, немає жодного сліду стека, який він прокручує; Найкраще, що ви можете зробити - це захопити його та зареєструвати на об’єкті завдання, якщо такий об’єкт є. Однак він перемагає первинну силу винятків: ви повинні перевірити їх, і ви можете ігнорувати їх без додаткових зусиль , тоді як в однопотоковому коді виняток обов’язково запустить відповідні дії (навіть якщо це означає припинення вашої програми).

Як мовні реалізації або бібліотеки повинні підтримувати помилки в паралельному коді?

Мені більше подобаються зворотні виклики за помилки, з якими можна впоратися. І їх можна змусити працювати просто чудово асинхронно ...

Але для помилок, з якими не вдається впоратися, справді виняткових помилок, я вважаю, що відповідна інформація зберігається, а програма припиняється. Оскільки це, як правило, здійснюється через якийсь глобальний обробник помилок, так чи інакше, я не бачу необхідності перекручувати винятки в щось, що для цього працює - але краща підтримка платформи для виявлення критичних помилок та створення пам’яті пам’яті тощо було б непогано.

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