Асинхронная архитектура с корутинами — бесплатный тест онлайн

Вопрос 1 из 30

Какой контракт языка проявляется в этом примере? Нужна именно центральная гарантия раздела «Планировщик».

local ready={}
local function spawn(fn) ready[#ready+1]=coroutine.create(fn) end
while #ready>0 do
  local co=table.remove(ready,1)
  local ok,reason=coroutine.resume(co)
  if not ok then report(reason) elseif coroutine.status(co)~="dead" then ready[#ready+1]=co end
end

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

Вопрос 2 из 30

Что следует изменить во входе, чтобы проверить скрытое ограничение? Нужен отрицательный сценарий для раздела «Планировщик».

local function reproduce_case()
  local ready={}
  local function spawn(fn) ready[#ready+1]=coroutine.create(fn) end
  while #ready>0 do
    local co=table.remove(ready,1)
    local ok,reason=coroutine.resume(co)
    if not ok then report(reason) elseif coroutine.status(co)~="dead" then ready[#ready+1]=co end
  end
end
reproduce_case()

Второй запуск раздела «Планировщик» нужен, чтобы увидеть: Возможность yield не уменьшает полномочия функции, доступной из окружения. Второй запуск раздела «Планировщик» нужен, чтобы увидеть: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий. Второй запуск раздела «Планировщик» нужен, чтобы увидеть: Корутина, которая долго не yield, блокирует весь кооперативный цикл. Второй запуск раздела «Планировщик» нужен, чтобы увидеть: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. Второй запуск раздела «Планировщик» нужен, чтобы увидеть: Ожидание события связывают с регистрацией продолжения и однократным пробуждением.

Вопрос 3 из 30

Код переписывают без изменения внешнего поведения. Какой контракт должен сохраниться? Речь идёт о центральном правиле раздела «Планировщик».

do
  local ready={}
  local function spawn(fn) ready[#ready+1]=coroutine.create(fn) end
  while #ready>0 do
    local co=table.remove(ready,1)
    local ok,reason=coroutine.resume(co)
    if not ok then report(reason) elseif coroutine.status(co)~="dead" then ready[#ready+1]=co end
  end
end

После правки раздела «Планировщик» должно оставаться верным: Производительность оценивают по длине очередей, задержке пробуждения и объёму работы между yield. После правки раздела «Планировщик» должно оставаться верным: Потерянное событие или двойное resume возникают, если состояние ожидания меняется неатомарно. После правки раздела «Планировщик» должно оставаться верным: Планировщик корутин должен явно владеть очередью готовых задач и правилом справедливости. После правки раздела «Планировщик» должно оставаться верным: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные. После правки раздела «Планировщик» должно оставаться верным: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние.

Вопрос 4 из 30

В модуле меняют «Планировщик» и хотят сохранить диагностируемость. Какой подход надёжнее? Ответ должен выражать проверяемое следствие раздела «Планировщик».

В рабочем решении раздела «Планировщик» учитывают: Возможность yield не уменьшает полномочия функции, доступной из окружения. В рабочем решении раздела «Планировщик» учитывают: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. В рабочем решении раздела «Планировщик» учитывают: Ожидание события связывают с регистрацией продолжения и однократным пробуждением. В рабочем решении раздела «Планировщик» учитывают: Корутина, которая долго не yield, блокирует весь кооперативный цикл. В рабочем решении раздела «Планировщик» учитывают: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий.

Вопрос 5 из 30

Что помогает не переносить в раздел «Планировщик» привычки из другого языка или среды? Выберите описание, объединяющее механизм и границу раздела «Планировщик».

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

Вопрос 6 из 30

Что нельзя заменить привычкой из другого языка при чтении этого кода? Ответ должен описывать основной механизм раздела «Ожидание событий».

local waiting={}
local function await(key)
  waiting[key]=coroutine.running()
  return coroutine.yield("wait",key)
end
local function publish(key,value)
  local co=waiting[key]; waiting[key]=nil
  if co then schedule(co,value) end
end

Поведение строки из раздела «Ожидание событий» определяется правилом: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий. Поведение строки из раздела «Ожидание событий» определяется правилом: Ожидание события связывают с регистрацией продолжения и однократным пробуждением. Поведение строки из раздела «Ожидание событий» определяется правилом: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние. Поведение строки из раздела «Ожидание событий» определяется правилом: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные. Поведение строки из раздела «Ожидание событий» определяется правилом: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом.

Вопрос 7 из 30

Что не видно по одному успешному запуску этого кода? Выберите именно проверяемую границу раздела «Ожидание событий».

local function reproduce_case()
  local waiting={}
  local function await(key)
    waiting[key]=coroutine.running()
    return coroutine.yield("wait",key)
  end
  local function publish(key,value)
    local co=waiting[key]; waiting[key]=nil
    if co then schedule(co,value) end
  end
end
reproduce_case()

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

Вопрос 8 из 30

Какое правило должно остаться наблюдаемым после правки? Нужен основной контракт раздела «Ожидание событий».

do
  local waiting={}
  local function await(key)
    waiting[key]=coroutine.running()
    return coroutine.yield("wait",key)
  end
  local function publish(key,value)
    local co=waiting[key]; waiting[key]=nil
    if co then schedule(co,value) end
  end
end

Новая реализация раздела «Ожидание событий» обязана соблюдать: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. Новая реализация раздела «Ожидание событий» обязана соблюдать: Ожидание события связывают с регистрацией продолжения и однократным пробуждением. Новая реализация раздела «Ожидание событий» обязана соблюдать: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий. Новая реализация раздела «Ожидание событий» обязана соблюдать: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние. Новая реализация раздела «Ожидание событий» обязана соблюдать: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные.

Вопрос 9 из 30

В модуле меняют «Ожидание событий» и хотят сохранить диагностируемость. Какой подход надёжнее? Нужна эксплуатационная граница раздела «Ожидание событий».

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

Вопрос 10 из 30

Что помогает не переносить в раздел «Ожидание событий» привычки из другого языка или среды? Выберите описание, объединяющее механизм и границу раздела «Ожидание событий».

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

Вопрос 11 из 30

Какое правило Lua нужно применить, чтобы верно прочитать этот фрагмент? Выберите основное правило раздела «Отмена».

local task={state="running",cleanups={}}
function task:cancel()
  if self.state~="running" then return false end
  self.state="cancelled"
  for i=#self.cleanups,1,-1 do self.cleanups[i]() end
  return true
end

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

Вопрос 12 из 30

Какое последствие проявится только при другом входе или повторном вызове? Нужен отрицательный сценарий для раздела «Отмена».

local function reproduce_case()
  local task={state="running",cleanups={}}
  function task:cancel()
    if self.state~="running" then return false end
    self.state="cancelled"
    for i=#self.cleanups,1,-1 do self.cleanups[i]() end
    return true
  end
end
reproduce_case()

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

Вопрос 13 из 30

Какой результат обязан подтверждать регрессионный тест после правки? Выберите гарантию, определяющую раздел «Отмена».

do
  local task={state="running",cleanups={}}
  function task:cancel()
    if self.state~="running" then return false end
    self.state="cancelled"
    for i=#self.cleanups,1,-1 do self.cleanups[i]() end
    return true
  end
end

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

Вопрос 14 из 30

После редкого сбоя команда спорит о разделе «Отмена». Какой вывод должен попасть в код и тесты? Нужна эксплуатационная граница раздела «Отмена».

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

Вопрос 15 из 30

Какое утверждение о разделе «Отмена» наиболее полное и точное? Ответ должен охватывать весь раздел «Отмена».

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

Вопрос 16 из 30

На каком правиле держится поведение этого кода? Выберите основное правило раздела «Распространение ошибок».

local ok,value=coroutine.resume(task.co,event)
if not ok then
  task.state="failed"
  task.error=debug.traceback(task.co,tostring(value))
  reject_dependents(task)
end

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

Вопрос 17 из 30

Какую границу стоит сделать явной в регрессионной проверке? Нужен отрицательный сценарий для раздела «Распространение ошибок».

local function reproduce_case()
  local ok,value=coroutine.resume(task.co,event)
  if not ok then
    task.state="failed"
    task.error=debug.traceback(task.co,tostring(value))
    reject_dependents(task)
  end
end
reproduce_case()

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

Вопрос 18 из 30

Что должно пережить замену вспомогательных функций и имён переменных? Речь идёт о центральном правиле раздела «Распространение ошибок».

do
  local ok,value=coroutine.resume(task.co,event)
  if not ok then
    task.state="failed"
    task.error=debug.traceback(task.co,tostring(value))
    reject_dependents(task)
  end
end

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

Вопрос 19 из 30

Команда меняет раздел «Распространение ошибок» в рабочем модуле. На какое решение можно опереться при повторном запуске и отказе зависимости? Ответ должен выражать проверяемое следствие раздела «Распространение ошибок».

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

Вопрос 20 из 30

Какое правило лучше всего описывает границы раздела «Распространение ошибок»? Выберите описание, объединяющее механизм и границу раздела «Распространение ошибок».

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

Вопрос 21 из 30

В чём ключ к разбору строки «local co=coroutine.create(assert(load(task.source,"task","t",env)))»? Нужна именно центральная гарантия раздела «Риски безопасности».

local env=sandbox_for(task.owner)
local co=coroutine.create(assert(load(task.source,"task","t",env)))
register_limits(co,task.owner)
schedule(co)

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

Вопрос 22 из 30

Какой риск останется незамеченным, если выполнить код только один раз? Выберите именно проверяемую границу раздела «Риски безопасности».

local function reproduce_case()
  local env=sandbox_for(task.owner)
  local co=coroutine.create(assert(load(task.source,"task","t",env)))
  register_limits(co,task.owner)
  schedule(co)
end
reproduce_case()

На другом входе раздела «Риски безопасности» нужно проверить: Возможность yield не уменьшает полномочия функции, доступной из окружения. На другом входе раздела «Риски безопасности» нужно проверить: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий. На другом входе раздела «Риски безопасности» нужно проверить: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. На другом входе раздела «Риски безопасности» нужно проверить: Корутина, которая долго не yield, блокирует весь кооперативный цикл. На другом входе раздела «Риски безопасности» нужно проверить: Ожидание события связывают с регистрацией продолжения и однократным пробуждением.

Вопрос 23 из 30

Какой инвариант нельзя потерять при упрощении этого фрагмента? Речь идёт о центральном правиле раздела «Риски безопасности».

do
  local env=sandbox_for(task.owner)
  local co=coroutine.create(assert(load(task.source,"task","t",env)))
  register_limits(co,task.owner)
  schedule(co)
end

Регрессионный контракт раздела «Риски безопасности» требует: Планировщик корутин должен явно владеть очередью готовых задач и правилом справедливости. Регрессионный контракт раздела «Риски безопасности» требует: Ожидание события связывают с регистрацией продолжения и однократным пробуждением. Регрессионный контракт раздела «Риски безопасности» требует: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные. Регрессионный контракт раздела «Риски безопасности» требует: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. Регрессионный контракт раздела «Риски безопасности» требует: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние.

Вопрос 24 из 30

Нужно сделать поведение «Риски безопасности» предсказуемым для следующего разработчика. Что выбрать? Выберите практическое следствие раздела «Риски безопасности».

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

Вопрос 25 из 30

Какое утверждение о разделе «Риски безопасности» точно и не обещает лишнего? Нужна полная формулировка раздела «Риски безопасности».

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

Вопрос 26 из 30

Что нельзя заменить привычкой из другого языка при чтении этого кода? Нужна именно центральная гарантия раздела «Контроль производительности».

metrics.gauge("scheduler_ready",#ready)
metrics.gauge("scheduler_waiting",count(waiting))
metrics.observe("scheduler_resume_ms",resume_elapsed)
if work_units>budget then reschedule(co) end

Строку из раздела «Контроль производительности» нужно читать так: Потерянное событие или двойное resume возникают, если состояние ожидания меняется неатомарно. Строку из раздела «Контроль производительности» нужно читать так: Планировщик корутин должен явно владеть очередью готовых задач и правилом справедливости. Строку из раздела «Контроль производительности» нужно читать так: Производительность оценивают по длине очередей, задержке пробуждения и объёму работы между yield. Строку из раздела «Контроль производительности» нужно читать так: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные. Строку из раздела «Контроль производительности» нужно читать так: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние.

Вопрос 27 из 30

Какой отказ должен быть воспроизводимым в тесте? Выберите именно проверяемую границу раздела «Контроль производительности».

local function reproduce_case()
  metrics.gauge("scheduler_ready",#ready)
  metrics.gauge("scheduler_waiting",count(waiting))
  metrics.observe("scheduler_resume_ms",resume_elapsed)
  if work_units>budget then reschedule(co) end
end
reproduce_case()

Граничный тест раздела «Контроль производительности» должен показать: Возможность yield не уменьшает полномочия функции, доступной из окружения. Граничный тест раздела «Контроль производительности» должен показать: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние. Граничный тест раздела «Контроль производительности» должен показать: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий. Граничный тест раздела «Контроль производительности» должен показать: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. Граничный тест раздела «Контроль производительности» должен показать: Ожидание события связывают с регистрацией продолжения и однократным пробуждением.

Вопрос 28 из 30

Какой смысл фрагмента нельзя спрятать в комментарии вместо проверки? Выберите гарантию, определяющую раздел «Контроль производительности».

do
  metrics.gauge("scheduler_ready",#ready)
  metrics.gauge("scheduler_waiting",count(waiting))
  metrics.observe("scheduler_resume_ms",resume_elapsed)
  if work_units>budget then reschedule(co) end
end

После упрощения кода раздела «Контроль производительности» по-прежнему верно: Производительность оценивают по длине очередей, задержке пробуждения и объёму работы между yield. После упрощения кода раздела «Контроль производительности» по-прежнему верно: Планировщик обязан ограничивать источники событий и данные, если задачи недоверенные. После упрощения кода раздела «Контроль производительности» по-прежнему верно: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние. После упрощения кода раздела «Контроль производительности» по-прежнему верно: Потерянное событие или двойное resume возникают, если состояние ожидания меняется неатомарно. После упрощения кода раздела «Контроль производительности» по-прежнему верно: Планировщик корутин должен явно владеть очередью готовых задач и правилом справедливости.

Вопрос 29 из 30

В модуле меняют «Контроль производительности» и хотят сохранить диагностируемость. Какой подход надёжнее? Ответ должен выражать проверяемое следствие раздела «Контроль производительности».

В разделе «Контроль производительности» нельзя оставлять неявным условие: Ожидание события связывают с регистрацией продолжения и однократным пробуждением. В разделе «Контроль производительности» нельзя оставлять неявным условие: Ошибка внутри корутины должна попасть владельцу задачи с traceback и контекстом. В разделе «Контроль производительности» нельзя оставлять неявным условие: Возможность yield не уменьшает полномочия функции, доступной из окружения. В разделе «Контроль производительности» нельзя оставлять неявным условие: Проглатывание неуспешного resume оставляет зависшие ожидания и неполное состояние. В разделе «Контроль производительности» нельзя оставлять неявным условие: Большое число корутин дешево лишь при коротком состоянии и дисциплине ожиданий.

Вопрос 30 из 30

Что нельзя вывести из одного удачного примера, но нужно знать о разделе «Контроль производительности»? Ответ должен охватывать весь раздел «Контроль производительности».

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