IPC и обмен данными — бесплатный тест онлайн

Вопрос 1 из 30

Что произойдёт после выполнения фрагмента «Каналы»?

pipe my $r,my $w or die $!;
my $pid=fork();
if(!$pid){ close $r; print {$w} $msg; close $w; exit }
close $w; my $data=do{local $/;<$r>};

Каждая ветвь не закрывает неиспользуемый конец, поэтому родитель увидит EOF после закрытия записи ребёнком. Для результата здесь достаточно учесть лишь такое условие: Запись до PIPE_BUF может быть атомарной между писателями на POSIX, но большие сообщения могут перемешиваться. Каждая ветвь закрывает неиспользуемый конец, поэтому родитель увидит EOF после закрытия записи ребёнком. Непосредственным итогом выполнения будет: Читатель может ждать EOF бесконечно, потому что хотя бы одна копия записывающего конца остаётся открытой. Показанная версия изначально работает как исправленная: Каждая ветвь явно закрывает неиспользуемый конец канала; это часть протокола, а не косметика.

Вопрос 2 из 30

Что в этом примере с `$sock`, `$host` и `$port` происходит на самом деле?

my $sock=IO::Socket::INET->new(PeerAddr=>$host,PeerPort=>$port,Proto=>'tcp',Timeout=>5) or die $!;

Исходная реализация уже содержит нужную защиту: Длина кадра задаёт границу сообщения; перед выделением памяти её нужно проверить по максимуму. Подключение имеет тайм-аут, но чтение и запись всё равно требуют собственных ограничений и обработки частичных операций. Поведение кода сводится к одной границе механизма: Один вызов sysread или syswrite не гарантирует обработку всего буфера; код обязан продолжать до нужного объёма или ошибки. В этой версии кода возникает другой результат: TCP не сохраняет границы сообщений, а строковое чтение предполагает согласованный разделитель и ограничение длины. Тайм-аут подключения автоматически ограничивает пятью секундами и все последующие операции чтения и записи.

Вопрос 3 из 30

Как ведёт себя участок «Очереди» при выполнении?

$queue->enqueue({job=>$id,payload=>$data});

Итог этого фрагмента полностью задаёт следующая оговорка: Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами. Непосредственным итогом выполнения будет: Если процесс падает после эффекта, но до ack, сообщение будет доставлено повторно; операция должна быть идемпотентной. Не верой в брокер, а очередь отделяет производителя от потребителя, но сообщение должно быть сериализуемым, ограниченным и иметь идентификатор. Очередь отделяет производителя от потребителя, но сообщение должно быть сериализуемым, ограниченным и иметь идентификатор. Исходная реализация уже содержит нужную защиту: Идентификатор и фиксация результата помогают безопасно пережить повторную доставку.

Вопрос 4 из 30

Что непосредственно следует из показанного кода с `$fh` и `read_modify_write`?

flock $fh, LOCK_EX or die $!;
read_modify_write($fh);
flock $fh, LOCK_UN;

Показанный участок сработает иначе: Проверка и создание разделены гонкой; два процесса могут одновременно считать блокировку свободной. Код из блока «Синхронизация» выполнится без вывода и не изменит показанные данные, поскольку все операции работают только с временной копией. Показанная версия изначально работает как исправленная: Атомарное создание исключает гонку проверки существования, но нужно решать проблему устаревшего lock-файла. Совместная advisory-блокировка работает только если все участники соблюдают тот же протокол. В показанном случае решающим становится только ограничение: Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных.

Вопрос 5 из 30

Какое утверждение точно описывает поведение фрагмента «Профилирование решения» с `$t`, `$bytes` и `$dt`?

my $t=time; my $bytes=transfer(); my $dt=time-$t;

В этой версии кода возникает другой результат: Тест в основном измеряет накладные расходы на тысячу сообщений, а не пропускную способность полезной нагрузки. Исходная реализация уже содержит нужную защиту: Профиль нагрузки и разогрев делают сравнение воспроизводимее и ближе к эксплуатации. Измерение даёт лишь грубую длительность; для сравнения IPC нужны монотонные часы, объём, распределение задержек и нагрузка. В показанном случае решающим становится только ограничение: Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации. Не только суммарное время, а измерение даёт лишь грубую длительность; для сравнения IPC нужны монотонные часы, объём, распределение задержек и нагрузка.

Вопрос 6 из 30

Что в этом примере с ключевыми операциями происходит на самом деле?

# producer -> broker -> workers -> database

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

Вопрос 7 из 30

Какой дефект проявится в варианте «Каналы» с `$r` и `$w`?

pipe my $r,my $w;
# оба процесса оставляют $w открытым

Читатель может ждать EOF бесконечно, потому что хотя бы одна копия записывающего конца остаётся открытой. Нежелательное поведение вводит предлагаемое решение: Каждая ветвь явно закрывает неиспользуемый конец канала; это часть протокола, а не косметика. Читатель не может ждать EOF бесконечно, потому что хотя бы одна копия записывающего конца остаётся открытой. Читатель может ждать EOF бесконечно, потому что хотя бы одна ссылка записывающего конца остаётся открытой. Дефект объясняется базовым поведением фрагмента: Каждая ветвь закрывает неиспользуемый конец, поэтому родитель увидит EOF после закрытия записи ребёнком.

Вопрос 8 из 30

Почему вариант с `$sock`, `$payload` и `$reply` нельзя считать безопасным для рабочих данных?

print {$sock} $payload;
my $reply=<$sock>;

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

Вопрос 9 из 30

Обычный случай проходит. Что в блоке «Очереди» всё же сделано неверно?

$queue->dequeue(); process(); ack();

Дефект объясняется базовым поведением фрагмента: Очередь отделяет производителя от потребителя, но сообщение должно быть сериализуемым, ограниченным и иметь идентификатор. Показанный сбой объясняется не кодом, а таким пределом механизма: Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами. Если процесс падает после эффекта, но до ack, сообщение будет доставлено повторно; операция должна быть идемпотентной. Показанный код уже соблюдает правило «Практические очереди обычно дают доставку как минимум один раз; «ровно один раз» достигается дизайном эффекта и хранилища, а не верой в брокер», поэтому отдельного дефекта нет. Нежелательное поведение вводит предлагаемое решение: Идентификатор и фиксация результата помогают безопасно пережить повторную доставку.

Вопрос 10 из 30

Почему участок с `$lock` и `$l` ненадёжен на пограничном входе?

if(!-e $lock){ open my $l,'>',$lock }

Основная проблема здесь — сам результат штатного случая: Совместная advisory-блокировка работает только если все участники соблюдают тот же протокол. Главный риск этого участка задаёт другое ограничение механизма: Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных. Показанный код уже соблюдает правило «Синхронизация должна иметь атомарную операцию, порядок захвата, тайм-аут и сценарий восстановления владельца после аварии», поэтому отдельного дефекта нет. Проверка и создание разделены гонкой; два процесса могут одновременно считать блокировку свободной. Источником дефекта становится само изменение: Атомарное создание исключает гонку проверки существования, но нужно решать проблему устаревшего lock-файла.

Вопрос 11 из 30

Какой риск связан именно с операциями `send_one_byte`?

for(1..1000){ send_one_byte() }

Показанный код уже соблюдает правило «Профилируют сериализацию, копирование, системные вызовы, ожидание и обратное давление отдельно, а не только суммарное время», поэтому отдельного дефекта нет. Тест в основном измеряет накладные расходы на тысячу сообщений, а не пропускную способность полезной нагрузки. Дефект объясняется базовым поведением фрагмента: Измерение даёт лишь грубую длительность; для сравнения IPC нужны монотонные часы, объём, распределение задержек и нагрузка. Причину отказа точнее описывает соседняя граница темы: Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации. Нежелательное поведение вводит предлагаемое решение: Профиль нагрузки и разогрев делают сравнение воспроизводимее и ближе к эксплуатации.

Вопрос 12 из 30

Что нужно заметить при ревью фрагмента «Архитектурные компромиссы»?

# shared file polled every second

Опрос файла прост, но плохо масштабируется, создаёт задержку и сложные гонки при множестве писателей. Главный риск этого участка задаёт другое ограничение механизма: Самый быстрый канал в микротесте может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости. Дефект объясняется базовым поведением фрагмента: Брокер сглаживает всплески и отделяет темпы, но добавляет задержку, хранение состояния и необходимость повторной доставки. Источником дефекта становится само изменение: Разные требования разделены: низкая задержка локального запроса и долговечная фоновая работа. Опрос файла прост, но плохо масштабируется, не создаёт задержку и сложные гонки при множестве писателей.

Вопрос 13 из 30

Что именно стало надёжнее после изменения в блоке «Каналы»?

if ($pid) { close $w or die $! }
else { close $r or die $! }

Каждая ветвь явно не закрывает неиспользуемый конец канала; это часть протокола, а не косметика. После изменения сохраняется прежний дефект: Читатель может ждать EOF бесконечно, потому что хотя бы одна копия записывающего конца остаётся открытой. Каждая ветвь явно закрывает неиспользуемый конец канала; это часть протокола, а не косметика. Правка лишь воспроизводит исходное поведение: Каждая ветвь закрывает неиспользуемый конец, поэтому родитель увидит EOF после закрытия записи ребёнком. Каждая ветвь неявно закрывает неиспользуемый конец канала; это часть протокола, а не косметика.

Вопрос 14 из 30

Как показанная редакция «Сокеты» делает контракт проверяемым?

print {$sock} pack('N',length $payload),$payload;
read_exact($sock,4);

Длина кадра задаёт границу сообщения; перед выделением памяти её не нужно проверить по максимуму. Правка лишь воспроизводит исходное поведение: Подключение имеет тайм-аут, но чтение и запись всё равно требуют собственных ограничений и обработки частичных операций. Длина кадра задаёт границу сообщения; перед выделением памяти её нужно проверить по максимуму. После изменения сохраняется прежний дефект: TCP не сохраняет границы сообщений, а строковое чтение предполагает согласованный разделитель и ограничение длины. Правка решает задачу тем, что устраняет следующую границу: Один вызов sysread или syswrite не гарантирует обработку всего буфера; код обязан продолжать до нужного объёма или ошибки.

Вопрос 15 из 30

Почему этот вариант пригоднее для рабочего кода?

process_once($message_id,$payload); ack_after_commit();

Изменение формы записи само по себе обеспечивает правило «Практические очереди обычно дают доставку как минимум один раз; «ровно один раз» достигается дизайном эффекта и хранилища, а не верой в брокер». Идентификатор и фиксация результата помогают безопасно пережить повторную доставку. Правка лишь воспроизводит исходное поведение: Очередь отделяет производителя от потребителя, но сообщение должно быть сериализуемым, ограниченным и иметь идентификатор. После изменения сохраняется прежний дефект: Если процесс падает после эффекта, но до ack, сообщение будет доставлено повторно; операция должна быть идемпотентной. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами.

Вопрос 16 из 30

Как правка с `$l`, `$path` и `handle_existing` меняет поведение на неудобном входе?

sysopen my $l,$path,O_CREAT|O_EXCL|O_WRONLY,0600 or handle_existing();

После изменения сохраняется прежний дефект: Проверка и создание разделены гонкой; два процесса могут одновременно считать блокировку свободной. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных. Правка лишь воспроизводит исходное поведение: Совместная advisory-блокировка работает только если все участники соблюдают тот же протокол. Атомарное создание исключает гонку проверки существования, но нужно решать проблему устаревшего lock-файла. Атомарное создание исключает гонку проверки существования, но не нужно решать проблему устаревшего lock-файла.

Вопрос 17 из 30

Как показанная редакция «Профилирование решения» делает контракт проверяемым?

measure(messages=>10000,size=>4096,concurrency=>8,warmup=>1);

Правка лишь воспроизводит исходное поведение: Измерение даёт лишь грубую длительность; для сравнения IPC нужны монотонные часы, объём, распределение задержек и нагрузка. После правки перестаёт проявляться предел механизма: Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации. Профиль нагрузки и разогрев делают сравнение воспроизводимее и ближе к эксплуатации. После изменения сохраняется прежний дефект: Тест в основном измеряет накладные расходы на тысячу сообщений, а не пропускную способность полезной нагрузки. Изменение формы записи само по себе обеспечивает правило «Профилируют сериализацию, копирование, системные вызовы, ожидание и обратное давление отдельно, а не только суммарное время».

Вопрос 18 из 30

Что меняется по существу после правки в блоке «Архитектурные компромиссы»?

# Unix socket for local RPC; queue for durable jobs

После изменения сохраняется прежний дефект: Опрос файла прост, но плохо масштабируется, создаёт задержку и сложные гонки при множестве писателей. Разные требования разделены: низкая задержка локального запроса и долговечная фоновая работа. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: Самый быстрый канал в микротесте может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости. Изменение формы записи само по себе обеспечивает правило «Выбор IPC делают по границам хоста, долговечности, порядку, задержке, объёму, обратному давлению и модели отказа». Правка лишь воспроизводит исходное поведение: Брокер сглаживает всплески и отделяет темпы, но добавляет задержку, хранение состояния и необходимость повторной доставки.

Вопрос 19 из 30

Что точнее всего описывает контракт механизма «Каналы»?

Общее правило темы «Каналы» сводится к частному результату: Каждая ветвь закрывает неиспользуемый конец, поэтому родитель увидит EOF после закрытия записи ребёнком. Главный ориентир — не допустить следующую ситуацию: Читатель может ждать EOF бесконечно, потому что хотя бы одна копия записывающего конца остаётся открытой. Однонаправленный pipe передаёт поток символов без границ сообщений; формат и завершение нужно определить отдельно. Однонаправленный pipe передаёт поток байтов без границ сообщений; формат и завершение не нужно определить отдельно. Однонаправленный pipe передаёт поток байтов без границ сообщений; формат и завершение нужно определить отдельно.

Вопрос 20 из 30

Какую закономерность проверяют задания темы «Сокеты»?

Сокетный протокол должен описывать кадрирование, кодировку, лимиты, тайм-ауты, завершение и версию сообщений. Для всех случаев темы подходит одно изменение: Длина кадра задаёт границу сообщения; перед выделением памяти её нужно проверить по максимуму. Сокетный протокол не должен описывать кадрирование, кодировку, лимиты, тайм-ауты, завершение и версию сообщений. Общее правило темы «Сокеты» сводится к частному результату: Подключение имеет тайм-аут, но чтение и запись всё равно требуют собственных ограничений и обработки частичных операций. Главный ориентир — не допустить следующую ситуацию: TCP не сохраняет границы сообщений, а строковое чтение предполагает согласованный разделитель и ограничение длины.

Вопрос 21 из 30

Какой принцип объясняет три кодовых примера блока «Очереди»?

Весь контракт блока обеспечивает такая правка: Идентификатор и фиксация результата помогают безопасно пережить повторную доставку. Общее правило темы «Очереди» сводится к частному результату: Очередь отделяет производителя от потребителя, но сообщение должно быть сериализуемым, ограниченным и иметь идентификатор. Правило «Практические очереди обычно дают доставку как минимум один раз; «ровно один раз» достигается дизайном эффекта и хранилища, а не верой в брокер» гарантирует, что ограничение «Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами» больше не проявится. Главный ориентир — не допустить следующую ситуацию: Если процесс падает после эффекта, но до ack, сообщение будет доставлено повторно; операция должна быть идемпотентной. Практические очереди обычно дают доставку как минимум один раз; «ровно один раз» достигается дизайном эффекта и хранилища, а не верой в брокер.

Вопрос 22 из 30

Какое правило связывает пять заданий блока «Синхронизация»?

Один приём полностью закрывает тему: Атомарное создание исключает гонку проверки существования, но нужно решать проблему устаревшего lock-файла. Общее правило темы «Синхронизация» сводится к частному результату: Совместная advisory-блокировка работает только если все участники соблюдают тот же протокол. Главный ориентир — не допустить следующую ситуацию: Проверка и создание разделены гонкой; два процесса могут одновременно считать блокировку свободной. Синхронизация должна иметь атомарную операцию, порядок захвата, тайм-аут и сценарий восстановления владельца после аварии. Правило «Синхронизация должна иметь атомарную операцию, порядок захвата, тайм-аут и сценарий восстановления владельца после аварии» гарантирует, что ограничение «Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных» больше не проявится.

Вопрос 23 из 30

Что точнее всего описывает контракт механизма «Профилирование решения»?

Общее правило темы «Профилирование решения» сводится к частному результату: Измерение даёт лишь грубую длительность; для сравнения IPC нужны монотонные часы, объём, распределение задержек и нагрузка. Основной принцип блока описывает только такой риск: Тест в основном измеряет накладные расходы на тысячу сообщений, а не пропускную способность полезной нагрузки. Профилируют сериализацию, копирование, системные вызовы, ожидание и обратное давление отдельно, а не только суммарное время. Общее правило исчерпывается единственной правкой: Профиль нагрузки и разогрев делают сравнение воспроизводимее и ближе к эксплуатации. Правило «Профилируют сериализацию, копирование, системные вызовы, ожидание и обратное давление отдельно, а не только суммарное время» гарантирует, что ограничение «Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации» больше не проявится.

Вопрос 24 из 30

Какое положение темы «Архитектурные компромиссы» помогает выбрать надёжную реализацию?

Правило «Выбор IPC делают по границам хоста, долговечности, порядку, задержке, объёму, обратному давлению и модели отказа» гарантирует, что ограничение «Самый быстрый канал в микротесте может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости» больше не проявится. Выбор IPC делают по границам хоста, долговечности, порядку, задержке, объёму, обратному давлению и модели отказа. Весь контракт блока обеспечивает такая правка: Разные требования разделены: низкая задержка локального запроса и долговечная фоновая работа. Общее правило темы можно свести к предотвращению одного сбоя: Опрос файла прост, но плохо масштабируется, создаёт задержку и сложные гонки при множестве писателей. Общее правило темы «Архитектурные компромиссы» сводится к частному результату: Брокер сглаживает всплески и отделяет темпы, но добавляет задержку, хранение состояния и необходимость повторной доставки.

Вопрос 25 из 30

Какое различие в механизме «Каналы» чаще всего теряют при обобщении?

Запись до PIPE_BUF не может быть атомарной между писателями на POSIX, но большие сообщения могут перемешиваться. Запись до PIPE_BUF может быть атомарной между писателями на POSIX, но большие сообщения могут перемешиваться. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Базовое правило «Однонаправленный pipe передаёт поток байтов без границ сообщений; формат и завершение нужно определить отдельно» автоматически снимает указанную границу. Ограничение «Запись до PIPE_BUF может быть атомарной между писателями на POSIX, но большие сообщения могут перемешиваться» исчезает, если обычный пример один раз завершился успешно.

Вопрос 26 из 30

Какое ограничение механизма «Сокеты» нужно учитывать даже при корректной работе обычного примера?

Один вызов sysread или syswrite не гарантирует обработку всего буфера; код обязан продолжать до нужного объёма или ошибки. При strict и warnings отдельная проверка этой оговорки не требуется. Базовое правило «Сокетный протокол должен описывать кадрирование, кодировку, лимиты, тайм-ауты, завершение и версию сообщений» автоматически снимает указанную границу. Ограничение «Один вызов sysread или syswrite не гарантирует обработку всего буфера; код обязан продолжать до нужного объёма или ошибки» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке.

Вопрос 27 из 30

Как точнее всего обозначить границу безопасного использования приёма «Очереди»?

Режимы strict и warnings полностью снимают это ограничение. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Базовое правило «Практические очереди обычно дают доставку как минимум один раз; «ровно один раз» достигается дизайном эффекта и хранилища, а не верой в брокер» автоматически снимает указанную границу. Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами. Ограничение «Ядовитые сообщения требуют лимита попыток и отдельной очереди, иначе они блокируют поток бесконечными повторами» исчезает, если обычный пример один раз завершился успешно.

Вопрос 28 из 30

Какое различие в механизме «Синхронизация» чаще всего теряют при обобщении?

Базовое правило «Синхронизация должна иметь атомарную операцию, порядок захвата, тайм-аут и сценарий восстановления владельца после аварии» автоматически снимает указанную границу. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. После включения strict и warnings указанная граница больше не может проявиться. Ограничение «Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных» исчезает, если обычный пример один раз завершился успешно. Блокировка не защищает внешние эффекты автоматически и не заменяет транзакцию базы данных.

Вопрос 29 из 30

Что остаётся верным о теме «Профилирование решения», если учитывать контекст, отказ и побочный эффект?

Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации. Базовое правило «Профилируют сериализацию, копирование, системные вызовы, ожидание и обратное давление отдельно, а не только суммарное время» автоматически снимает указанную границу. Ограничение «Микротест на localhost не предсказывает поведение сети при потерях и очередях, но помогает локализовать накладные расходы реализации» исчезает, если обычный пример один раз завершился успешно. Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен.

Вопрос 30 из 30

Какой вывод о механизме «Архитектурные компромиссы» выдерживает проверку на пограничном входе?

Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Самый быстрый канал в микротесте не может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости. Самый быстрый канал в микротесте может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости. Ограничение «Самый быстрый канал в микротесте может быть худшим выбором, если он не переживает перезапуск или не даёт наблюдаемости» исчезает, если обычный пример один раз завершился успешно. Базовое правило «Выбор IPC делают по границам хоста, долговечности, порядку, задержке, объёму, обратному давлению и модели отказа» автоматически снимает указанную границу.