Альтернатива - которая может (или не может) применяться к вашему делу - использовать поведение gen_event .
ОТКАЗ
Я говорю " может ", потому что это зависит от того, что ваши "работники" делают в вашем конкретном случае. Если вас интересует содержание их ответов, вы можете предпочесть не использовать этот подход, но в случае, если вас интересует только тот факт, что все работники выполнили свои задачи - например, рабочие процессы выполняют некоторые сложные вычисления. и сохраните их частичный результат в базе данных, так что вы готовы объединить партиалы - gen_event может быть маршрутом.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ
Итак ...
В OTP менеджер событий - это именованный объект, на который можно отправлять события.
События - это сообщения.
В диспетчере событий установлены ноль, один или несколько обработчиков событий. Когда менеджер событий получает уведомление о событии, оно будет обработано всеми установленными обработчиками событий.
Таким образом, в основном вместо одного руководителя и нескольких рабочих у вас есть менеджер событий и несколько обработчиков событий.
Затем вы можете использовать функцию gen_event: sync_notify / 2 :
sync_notify является синхронным в том смысле, что он вернется нормально после
событие было обработано всеми обработчиками событий.
Для получения дополнительной информации о * gen_event * посмотрите здесь и там .