почему много звонков schedule () в другое место?

shlex разделяет пробелы только по правилам оболочки, но не имеет отношения к трубам.

Он должен, однако, работать следующим образом:

import subprocess
import shlex

sp_ls = subprocess.Popen(shlex.split(r'ls -l'), stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE)
sp_sed = subprocess.Popen(shlex.split(r'sed "s/a/b/g"'), stdin = sp_ls.stdout, stdout = subprocess.PIPE, stderr = subprocess.PIPE)
sp_ls.stdin.close() # makes it similiar to /dev/null
output = sp_ls.communicate()[0] # which makes you ignore any errors.
print output

согласно к help(subprocess)

Replacing shell pipe line
-------------------------
output=`dmesg | grep hda`
==>
p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]

HTH

1
задан Mark 18 January 2019 в 08:00
поделиться

2 ответа

  1. Состояние некоторых задач изменилось, его необходимо обновить в schedule ().
  2. Некоторые задачи 'работают и еще много работы, график () для баланса.
0
ответ дан Mark 18 January 2019 в 08:00
поделиться

Поскольку существует много вызовов schedule () вне do_timer (), могу ли я сказать, что это является своего рода вытеснением? или какова цель?

для реальной ОС; большинство переключений задач происходит из-за того, что задача блокирует ожидание чего-либо (пользовательский ввод, сетевой пакет, дисковый ввод-вывод и т. д.) или задача разблокируется, потому что произошло то, что она ожидала (а разблокированная задача имеет более высокий приоритет и выгружает текущий запущенный более низкий приоритет задание).

Весь «переключение задач, вызванное таймером IRQ», в основном, является всего лишь запасным вариантом для защиты от вредоносных захватов ЦП (атаки типа «отказ в обслуживании»); а для обычного программного обеспечения в нормальных условиях вы можете отключить его (удалить schedule() из обработчика IRQ таймера), и никто не заметит и не позаботится. Примечание. Некоторые люди скажут, что это также относится к «незлонамеренным» задачам, связанным с процессором, но задачи, связанные с процессором, встречаются относительно редко, и (игнорируя тот факт, что планировщик Linux никогда не подходил для приоритетов задач) для задач, связанных с процессором. Лучше полагаться на эффективную систему приоритетов задач (например, дать задачам, связанным с ЦП, низкий приоритет, чтобы почти все их опередили).

Также обратите внимание, что различные курсы по теории ОС начинаются с концепций «настолько просто, что на самом деле это никогда не происходит на практике», которые почти всегда являются чисто циклическим планировщиком с задачами, которые никогда не блокируются (часто с помощью «Эй, мы можем точно предсказать»). будущее и точно знать, как долго каждое задание будет выполняться за «ерунду», что, в основном, хорошо в качестве первого шага («научиться ходить, прежде чем бежать»), но сосет большие соленые собачьи мячи, если за ним не последуют более реалистичные и более сложные концепции (улучшенные алгоритмы планирования, приоритеты задач, несколько алгоритмов одновременного планирования / «политики планировщика», многопроцессорные, интерактивные / чувствительные к задержке задачи, ...), потому что это оставляет ученику / жертве чуть больше дезинформации (например, когда-либо повторяющееся заблуждение "все переключатели задач вызваны ошибочным таймером IRQ").

do_timer () (@ sched.c) будет вызываться каждый раз при тайм-ауте таймера? Этот таймер основан на вызове прерывания x86?

Я предполагаю, что таймер был IRQ необработанного PIT-чипа (учитывая, что версия 0.11 для Linux была «разработчиком абсолютного новичка без намерения сделать это» «портативные» исторические памятные вещи от тысяч добровольцев, исправивших половину худших частей).

Также не забывайте, что планировщик использует время для двух разных вещей - «текущая задача использует слишком много процессорного времени», что почти никогда не имеет значения, и выяснение, когда задачи заблокированы / спят (например, потому что они вызвали sleep()) должен разблокироваться / проснуться. do_timer() может быть для любой из этих вещей и может быть для обоих (я не знаю, не глядя на это).

0
ответ дан Brendan 18 January 2019 в 08:00
поделиться
Другие вопросы по тегам:

Похожие вопросы: