Линус Торвальдс утвердил (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) включение в будущий выпуск ядра Linux 3.14 патчей с реализацией планировщика задач SCHED_DEADLINE (https://github.com/jlelli/sched-deadline), реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов.
Обычный планировщик задач не может обеспечить такое поведение, так как не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мкс в интервале 100 мкс) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.
URL: http://lwn.net/Articles/581491/rss
Новость: https://www.opennet.ru/opennews/art.shtml?num=38906
ну и здорово. Теперь gnu/linux будет операционной системой реального времени.
> ну и здорово. Теперь gnu/linux будет операционной системой реального времени.Всё равно xorg будет тормозить.
Хотя... я лично жду, что в ядре 3.14 у меня таки будет работать подсветка ноута, что называется, из коробки.
Баг ещё в 3.12 реквестировал)
а зачем нужна подсветка всего ноута? Подсветки экрана и клавиатуры мало?
Тем более что с помощью подсветки монитора можно освещать клавиатуру:)
И туалетную комнату.
это не для того чтоб xorg не тормозил.
> Хотя... я лично жду, что в ядре 3.14 у меня таки будет работать подсветка ноута, что
> называется, из коробки.Зависит от. Бывают на редкость кривые биосы, там приходится использовать вендорское управление питанием.
> ну и здорово. Теперь gnu/linux будет операционной системой реального времени.Уже очень давно и в разных вариантах (неванильных).
> Уже очень давно и в разных вариантах (неванильных).вот вот.
Как правило платных, и/или триальных. И такой тип как LinxOS вполне себе гинезис линукса.
да ладно вам, тот же opensuse с l4 идет свободно, латентность лучше чем у ядра NT
QNX больше не нужен?
Вот и славненько...
> QNX больше не нужен?
> Вот и славненько...Нужен, смотря какой. Хотя и 4,25 и 6
Странно, я уже много лет при сборки ядра вижу его в списке опций.
Ты видишь скорее всего планировщик IO deadline
Точно, спасибо.
Очередной гвоздь в крышку Bug 12309? :)
> Очередной гвоздь в крышку Bug 12309? :)Вахтёршу от начальника отдела отличаем, не?!
И как интересно реалтайм связан с таинственным 12309?
> И как интересно реалтайм связан с таинственным 12309?А никак особо. Если реалтаймная программа уповает что выделение памяти случится не быстрее чем за X - а кто ей это обещал?
Видимо эту, "риал-таймовую", программу спроектировал именно ты.
Причем специально для того, чтобы не признавать что обложался и перепутал планировщик процессов с планировщиков ввода/вывода.
> Видимо эту, "риал-таймовую", программу спроектировал именно ты.Чойта за жирнота??? 12309 может вылезти при выделении памяти программой. И пока ядро память не выкроит - управление не вернет. А теперь послушаем про планировщики...
Поясняю — твоя программа не становится рт, только из-за того, что ты её на рт-ядре запустил.
Андестенд? Не?Зыж
Во-вторых — баг закрыт.
В третьих — рт-программа "почувствует" указанный баг только в случае своппинга.
ззыж
Чтобы не быть голословным:
1. Вот так выглядит «хеловолд» для рт https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#A_Real...
2. После этого нужно настроить этот «хеловорд» в системе примерно так http://www.jackaudio.org/linux_rt_config
3. Вот теперь можно выпендриваться.
Пффф, придумают тоже ....
# chrt -f -p 99 ./hello
Ну, каждый раз запускать так процесс не камильфо.
А то прописал 1 раз и каждый запуск ./hello (например через dbus) ситема понимает "угу, рт-приоритет нужОн".
зыж
В смысле не нужны рутовые привилегии.
ззыж
Да, надеюсь ты то хоть понимаешь, что https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
>The standard Linux kernel only meets soft real-time requirements: it provides basic POSIX operations for userspace time handling but has no guarantees for hard timing deadlines. With Ingo Molnar's Realtime Preemption patch (referenced to as RT-Preempt in this document) and Thomas Gleixner's generic clock event layer with high resolution support, the kernel gains hard realtime capabilities.ядро уже(!!!) реалтаймовское? ☺
Просто не для всех достаточно хард(корное). ☻
Но в любом случае для повседневных задач (аля звук, пульс, джек) более чем достаточно.
Что кстати в джеке (пункт 2 выше) и сказано:
>t is very important to understand that you do NOT need an "RT kernel" to use RT scheduling (this is a very common misconception.)Всё. Теперь можно выпендриваться:
# cat /etc/security/limits.d/40-audio-rt.conf
@audio - rtprio 99
@audio - memlock unlimited
И хелловолд из примера работает (назначает сам себе приоритет) из под любого пользователя, кто входит в группу audio. Правда до сабжа (и без патчей из пункта 1) всё равно — current scheduling policy: SCHED_FIFO
> # chrt -f -p 99 ./helloman chrt
chrt [options] prio command [arg]...
chrt [options] -p [prio] pid-p у тебя лишняя, а -f на стоковом ядре итак по-умолчанию
И это не планировщик задач, это класс приоритета, такой же как и: SCHED_NORMAL,
SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_ISO, SCHED_IDLEPRIO.
Более того, чтоб его заюзать нужон schedtool патченый
Ах да, основной сайт тут: http://www.evidence.eu.com/sched_deadline.html
Там же есть ссылки на LWN, где есть бенчмарки, в которых этот DEADLINE
сливает обычному CFS с SCHED_FIFO.Но полюбасу, это плюшка вкусная, - теперь можно -RT патчи и не сувать,
для адекватной реакции вполне хватит нужные процессы поставить как дыдлайн
и спать спокойно. Нормальный Soft RealTime без замены кучи кода.
>Нормальный Soft RealTimeтак софт уже есть давно, со времен preempt патча и оптимизаций мьютексов и прочих биг локов. Разве это не hard realtime?
> Разве это не hard realtime?Они только мечтают. Hard RT это 5% отклонение от средних показателей.
Сейчас средняя задержка 6-8µs, зато бывают пики от 80 до 2500µsНо опять же, от железа зависит. 5% это на оооооооооооочень качественных
резисторах, кондёрах, катушках. С защитой от ЭМИ. итд, итп.В общем, у кого увидишь надпись Hard RealTime - плюнь им в рожу,
без заранее проверенного железа и замеров с него, всё маркетинговый бред.
> 5% это на оооооооооооочень качественных резисторах, кондёрах, катушках.Это всё в большей части используется в обвязках для питания. На кристалле это либо работает как нужно, либо нет и вместе с ними не работает сразу всё.
Да фигня это, павлин. Поставь всем задачам приоритет реалтайм и наслаждайся хард-реалтаймом :)
> Да фигня это, павлин. Поставь всем задачам приоритет реалтайм и наслаждайся хард-реалтаймом :)Открою маленький секрет: в Линуксе не бывает Hard RealTime в принципе. Это же Вам не DSP, не микроконтроллер и не ПЛИС! Там, где DRAM, нет Hard Real Time, за исключением специальных систем (железо + ОС + софт), которые могут грамотно управлять его работой. Даже QNX, VxWorks вам в этом не помогут - это всё Soft Real Time, как бы производители этих ОС не пиарились.
Это всё чушь. Будет хард RT или нет с DRAM завист требуемой гранулярности по времени. В пределах ms, например, всё можно.
Реалтайм - это про ГАРАНТИРОВАННОСТЬ времени реакции. Хард - про 100% гарантированность, софт - про <100% гарантированность (желаемый процент может быть задан). Так вот, само требуемое время реакции ТОЖЕ может быть задано, хотите - мкс, хотите - сутки. И уже потом смотрим соответствует или нет.
> Реалтайм - это про ГАРАНТИРОВАННОСТЬ времени реакции. Хард - про 100% гарантированность,
> софт - про <100% гарантированность (желаемый процент может быть задан). Так
> вот, само требуемое время реакции ТОЖЕ может быть задано, хотите -
> мкс, хотите - сутки. И уже потом смотрим соответствует или нет.Скажем так, профессиональные реал тайм оси создаются для обеспечения гарантированности реакции обычно не более 5 мкс, но это плохой показатель. Нормальный ориентир - 1 мкс плюс-минус несколько процентов, более-менее обеспечиваемые QNX. Но это всё равно Soft Real Time, т.к. 100% стабильности всё равно нет и не будет, т.к. обычные процессоры не позволяют управлять DRAM и кеш памятью, делая это автоматически. Это основная проблема, почему у реал тайм осей на обычных процессорах не хард, а софт реал тайм, в отличие от специализированных решений, у которых время срабатывания по прерыванию на несколько порядков ниже, а стабильность - 100%, без оговорок.
> Открою маленький секрет: в Линуксе не бывает Hard RealTime в принципе. Это
> же Вам не DSP, не микроконтроллер и не ПЛИС!На х86 реалтайм достаточно условный из-за дикого разброса времен cache hit/cache miss. Ну а многозадачки усугубляют ситуацию.
Павлин, причём здесь кондёры, резисторы и катушки, просвети публику, а?
Начинай отсюда http://lib.qrz.ru/node/28775 и http://library.ispu.ru:8001/metrolog/index.htm
> Начинай отсюда http://lib.qrz.ru/node/28775Павлин, это всё не про реальное время, а про качество питания, а оно мало влияет на реальное время.
>> Начинай отсюда http://lib.qrz.ru/node/28775
> Павлин, это всё не про реальное время, а про качество питания, а
> оно мало влияет на реальное время.монитор у тя в процессор впаян? кнопки с клавы прям в L1 кэш пишут, контроллер привода там же?
Пусти cyclictest и жмакай по мышу иль клаве, насладись линуксовым реалтаймом!
>>> Начинай отсюда http://lib.qrz.ru/node/28775
>> Павлин, это всё не про реальное время, а про качество питания, а
>> оно мало влияет на реальное время.
> монитор у тя в процессор впаян? кнопки с клавы прям в L1
> кэш пишут, контроллер привода там же?У меня лично микроконтроллеры и спец. микросхемы рулят монитором и кнопками с клавы, а контроллер привода - это отдельная ASIC. Ну а при чём здесь пассивные компоненты, которые ни на что в выч. технике не влияют, кроме как на стабильность работы устройств?
Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода короче делать. Если будут очень длинные то это будет не тот Real Time
> Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода
> короче делать. Если будут очень длинные то это будет не тот Real TimeВы не поверите (ц), но сотня метров оптики вдруг оказывается уже заметной на QDR IB.
> Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода
> короче делать. Если будут очень длинные то это будет не тот
> Real TimeВанга, ты? Google: EtherCAT
За одно закон Ома, проводимость материалов, закон Фарадея,
по дороге "Почему витая пара, витая", с чем курят STP/UTP
да ....чо уж там, начинай с Физики 5 класса.
>> Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода
>> короче делать. Если будут очень длинные то это будет не тот
>> Real Time
> Ванга, ты? Google: EtherCATХреновый этот EtherCAT в плане реального времени
> За одно закон Ома, проводимость материалов, закон Фарадея,
> по дороге "Почему витая пара, витая", с чем курят STP/UTP
> да ....чо уж там, начинай с Физики 5 класса.Витая пара, как и остальное перечисленное, не относится к реальному времени - это всего лишь линия передачи, у которой задержки, как у любой линии передачи, в основном зависят от параметров линии, материалов проводников и окружающей проводники среды. Всё это к реальному времени не относится.
> Всё это к реальному времени не относится.Хорошо, живи в мечтах.
не имеют отношения? а ты когда ни будь слышал что задержки можно сложить в кучу и получим не реалтайм ,а тормозилово. причем из-за компонентов будет вылетать план работы программ( точнее планировщика) . грубо говоря в отведенное время процесс не будет успевать проделать необходимый объем работы, что автоматом переводит систему из реалтайм в обычную. да уж а физику процессов бы подучил бы а?
> не имеют отношения? а ты когда ни будь слышал что задержки можно
> сложить в кучу и получим не реалтайм ,а тормозилово. причем из-за
> компонентов будет вылетать план работы программ( точнее планировщика) . грубо говоря
> в отведенное время процесс не будет успевать проделать необходимый объем работы,
> что автоматом переводит систему из реалтайм в обычную. да уж
> а физику процессов бы подучил бы а?Про физику всё написано выше. Остальное, что ты перечислил, относится к софту, а не к железу, обсуждаемому в данном диалоге. А софт - дело программиста, на то ему и платят з/п, чтобы он думал думалкой, а не задним местом, и не надеялся на бога или царя-батюшку. Программист должен всё учесть, все длины, задержки и прочие особенности конфигурации, с которой он имеет дело. А ежели кто думает, что железо само за него всё сделает... только это будет совсем другой реал тайм, не 100 КГц, а 100 Гц, но тоже вполне себе реал тайм, для кого-то.
согласен с тем что и обычный линух без патчей в какой то мере можно назвать реалтайм системой, все зависит от требований к времени реакции на определенное действие, но все же как то обычную сборку линуха или там фри не принято считать таковыми. а все потому что реалтайм как правило подразумевает более мизерные и строгие сроки реакции, а допуски работы самой электроники могут свести любую действительно реалтайм операционку к неприменимому варианту. тут все таки как и с безопасными системами важна не только ось , но и набор железа соответствующего заданию.
>что автоматом переводит систему из реалтайм в обычнуюЕсли учесть, что "реал-тайм" система отличается от "обычной" тем, что прибивает процессы которые "думают" дольше запланированного. И более ничем.
То в чем суть спора?
>>что автоматом переводит систему из реалтайм в обычную
> Если учесть, что "реал-тайм" система отличается от "обычной" тем, что прибивает
> процессы которые "думают" дольше запланированного. И более ничем.Не совсем: реал тайм обеспечивает гарантированное время реакции ВСЕЙ системы, которая как правило, включает много устройств, взаимодействующих друг с другом, поэтому всё - железо, софт (ОСи, драйверы, ПО), интерфейсы, протоколы... - на всех устройствах системы проектируются изначально с таким расчётом, чтобы обеспечивать требуемое время реакции.
> То в чем суть спора?
Павлин нам пел песню о том, что кондёры и другие пассивные компоненты сильно влияют на реал тайм. А мы Павлину разъясняли, что кондёры и реал тайм вещи абсолютно параллельные.
И даже линии связи между устройствами, про которые вспомнили в процессе обсуждения, хоть и дают задержку порядка 4.5 нс на метр, которую конечно же надо всегда учитывать, но учитывать её надо в любых системах, а не только реал тайм. В общем поболтали о само собой разумеющихся вещах.
>Не совсем: реал тайм обеспечивает гарантированное время реакции ВСЕЙ системы, которая как правило, включает много устройств, взаимодействующих друг с другом, поэтому всё - железо, софт (ОСи, драйверы, ПО), интерфейсы, протоколы...Нет. Только рт-процессов.
Более того, то что процесс получит свой квант (а он получит) не значит, что в/в и остальные устройства не будут в это время заняты. И разруливать это должен сам процесс.
Вот так.
>Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода короче делать. Если будут очень длинные то это будет не тот Real TimeТаки да. Если не согласны, идите-ка учите физику.
>>Если следовать логике pavlinux, то для повышения отзывчивости важно еще и провода короче делать. Если будут очень длинные то это будет не тот Real Time
> Таки да. Если не согласны, идите-ка учите физику.Таки нет, думайте головой, 5 нс на 1 метр вам вряд ли сильно помешает, по крайней мере на расстояниях в пару сотен метров.
> Таки нет, думайте головой, 5 нс на 1 метр вам вряд ли
> сильно помешает, по крайней мере на расстояниях в пару сотен метров.Таки да, думаю головой (и Вам того же желаю).
Во-первых, расстояния (между А и Б) в пару сотен метров (х) могут превратиться в n*х метров провода.
Во-вторых, даже х метров провода != y метров пути для сигнала, при y>x.
В-третьих, для RT (особенно на _опасных_ производствах) нужна калибровка на среднее прохождение сигнала, и там 5-10 нс вполне критичный показатель.
В-четвертых, из-за п. 3, таки нужно делать оптимальное расположение и длину проводки провода.А то таки будет очередной "Маяк", ЛАЭС, ЧАЭС.
Если чо, в местах, где нужон жесткий RT действует простое правило: "лучше перебздеть, чем недобдеть".
>>>> Начинай отсюда http://lib.qrz.ru/node/28775
>>> Павлин, это всё не про реальное время, а про качество питания, а
>>> оно мало влияет на реальное время.
>> монитор у тя в процессор впаян? кнопки с клавы прям в L1
>> кэш пишут, контроллер привода там же?
> У меня лично микроконтроллеры и спец. микросхемы рулят монитором и кнопками с
> клавы, а контроллер привода - это отдельная ASIC. Ну а при
> чём здесь пассивные компоненты, которые ни на что в выч. технике
> не влияют, кроме как на стабильность работы устройств?А причем тут вычисления и реалтайм?
---
Более того, кондёры/резисторы с погрешностью 5% это полбеды.
Есть такие дебилы, которые контакты золотят, не только на разъёмах,
но и на спаиваемых деталях, А ещё формула припоя, у тех же дибилов, секретная.
А ещё пайка ведётся в вакууме или криптоне.
>> Павлин, кончай крутить хвостом, это тебе не цирковая арена с медведями и
>> клоунами!
> Очень нужная информация.Если уж придираться, то:
- погрешность кондёров в 99,99% случаев ни на что не влияет,
- если нужна точность, то резисторы берут не 5%, а 1% или менее,
- ну а уж контакты золотить - это только про надёжность и агрессивные среды,
- формула припоя обычно китайская, а секретная она потому, что некоторые дeбилы в России берут китайское и продают в 100 раз дороже, как спец. товар,
- "пайка ведётся в вакууме или криптоне" - можно даже отправить на марс и там сделать сeкретную паяльную лабораторию :)
> резисторы берут не 5%, а 1% или менее,Цезиевые, в жидком гелии?
> и там сделать сeкретную паяльную лабораторию :)
Ща допью и полетим.
> монитор у тя в процессор впаян?Павлик, а у меня наоборот - процессор впаян в монитор.
> кнопки с клавы прям в L1 кэш пишут
Хуже того, кнопки прям в регистры процессора печатают - клава у меня виртуальная, ясен пень!
И всё это называется iPhone!!!
> И всё это называется iPhone!!!А, так вот почему сообщения с трёх ников...
>> И всё это называется iPhone!!!
> А, так вот почему сообщения с трёх ников...Я так понимаю, Вы и есть Шерлок Холмс? А где Доктор Ватсон?
Да здесь я, здесь. Холмс, но как это воможно ?
>> А, так вот почему сообщения с трёх ников...
> Я так понимаю, Вы и есть Шерлок Холмс? А где Доктор Ватсон?Предлагаю обратить внимание на п. 6 правил форума: http://wiki.opennet.ru/ForumHelp -- ведите себя прилично, профессор.
> Пусти cyclictest и жмакай по мышу иль клаве, насладись линуксовым реалтаймом!Ты так и не ответил - при чем тут питание. Признайся уже что облажался :).
>> Разве это не hard realtime?
> Они только мечтают. Hard RT это 5% отклонение от средних показателей.
> Сейчас средняя задержка 6-8µs, зато бывают пики от 80 до 2500µs
> Но опять же, от железа зависит. 5% это на оооооооооооочень качественных
> резисторах, кондёрах, катушках. С защитой от ЭМИ. итд, итп.
> В общем, у кого увидишь надпись Hard RealTime - плюнь им в
> рожу,
> без заранее проверенного железа и замеров с него, всё маркетинговый бред.Не, железо тут ни причем. По крайней мере то что ты описал. Всякие железки обрабатывающие прерывания - вот где засада. Оно тебя удерживает на прерывании а сама требует реал тайма жесткого. А резюк с индуктивностью никто силами ЦПУ не опрашивает, если конечно препод был трезв при выдаче ТЗ на курсач.
Хард реал тайм в QNX , и собсно без реал-тайма в голове реал-таймовый софт не пишется. Проверено уже не раз, и не только мною.
>Hard RT это 5% отклонение от средних показателей.Hard RT - это когда система by design гарантирует верхний предел времени отклика (причем не важно, какой), и не при каких обстоятельствах он не будет превышен. Заявки типа "допустимое отклонение 5%" - это типичный soft RT.
>>Hard RT это 5% отклонение от средних показателей.
> Hard RT - это когда система by design гарантирует верхний предел времени
> отклика (причем не важно, какой), и не при каких обстоятельствах он
> не будет превышен. Заявки типа "допустимое отклонение 5%" - это типичный
> soft RT.Отклонение не более ±5% - это промышленно допустимое.
Дальнейшая точность корректируется программно либо введением дублирующих систем.
>>>Hard RT это 5% отклонение от средних показателей.
>> Hard RT - это когда система by design гарантирует верхний предел времени
>> отклика (причем не важно, какой), и не при каких обстоятельствах он
>> не будет превышен. Заявки типа "допустимое отклонение 5%" - это типичный
>> soft RT.
> Отклонение не более ±5% - это промышленно допустимое.
> Дальнейшая точность корректируется программно либо введением дублирующих систем.Смысл сообщения был в том, что опеределение soft/hard никак не связано с величиной отклонения
> гарантированное время выполнения, независимо от общего количества обслуживаемых процессовага, и будет у нас как с мигалками, когда все с ними в сверхприоритете
Не, не, не, SCHED_DEADLINE - это куча мигалок на перекрытой трассе,
которые меняются между собой за первое место, а для соблюдения демократии
нужно пускать набитый троллейбус с такой же скоростью :)
> нужно пускать набитый троллейбус с такой же скоростью :)Боюсь оттуда станут сыпаться пассажиры.
Означает ли это, что ПО для работы с музыкой будет работать без шаманства (установки RT-ядер)?
> Означает ли это, что ПО для работы с музыкой будет работать без
> шаманства (установки RT-ядер)?Скорее всего да. Дрова к карте пересмотреть нуно. А остальное - только после пересборки ядра.
> Означает ли это, что ПО для работы с музыкой будет работать без
> шаманства (установки RT-ядер)?Если пропатчишь свое ПО, чтобы оно использовало SCHED_DEADLINE, то, может быть, да. Хотя RT-патчи все равно не помешают, т.к. в них устраняется возможность "залипания" ядра на неконтролируемое время в коде некоторых подсистем.
Когда Kolivas предлагал подобное, ответ был - второму планировщику задач в ядре не бывать.
> Когда Kolivas предлагал подобное, ответ был - второму планировщику задач в ядре
> не бывать.Да, Кона быдляли все кому не лень. А ушел он и спохватлись. " ... друг, оставь покурить. А в ответ тишина, это он не вернулся из боя"
> Когда Kolivas предлагал подобноеОн не позиционировался на реалтайм. Он в основном оптимизировался на ускорение работы десктопов с 1 ... несколько процессоров.
Уряяяя!!!! Больше не буду накатывать rt-пячи на ведро. Наконец-то!
> Уряяяя!!!! Больше не буду накатывать rt-пячи на ведро. Наконец-то!Ты всё перепутал. Продожай страдать.
На самом деле с 3-х версий без рт-патчей уже можно обходиться. И так Джек нормально работает.
В ринципе РТ и сейчас работает. Как то написал прогу, перехватил все прерывания. В обработчик поставил логирование. Запустил на рабочем серваке. Прога рабала чуть-чуть а птом перестала. У килом не убивалаь никак, логит все попытки ее сигналами разными прибить, а не аумирает скина. Я маны покурил, смотлю реалтаймовые номера есть для кила. Вообщем тока так я ее и прибить смог. Та что ребята, реал-тайм необходим.
> В ринципе
> Прога рабала
> а птом
> У килом не убивалаь
> а не аумирает скина
> смотлю
> Та что ребятаУважаемый Васька, на каком таком поганом языке вы разговариваете?
Гы
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>int main(void)
{
pid_t pid;
int st;
switch (pid = fork()) {
case -1:
perror("fork");
exit(1);
case 0:
printf("форкнулся!!!\n");
exit(5);
default:
waitpid(pid, &st, 0);
}
return 0;
}# gcc fork.c
# schedtool -E -t 10000:10000 -e ./a.out
fork: Resource temporarily unavailable:facepalm:
У вас копипаста не работает.