LINUX.ORG.RU

вот это статья!

soko1 ★★★★★
()

Конечно молодец и все хорошо ) думаю создание этой статьи помогло тебе самому разобраться в системе. но для начинающих я бы все таки рекомандавал того же Робачевского.

Nesk
()

Очень хорошая новость, ни разу не бойан. Аффтар, продолжай в том же духе.

psy-janizary
()

после семинара по сигналам, ждем соответствующую статью!

Nesk
()
Ответ на: комментарий от sanets

Эта статья - часть курса "ОС Linux" который я проводил в Вологде. Спасибо за отзывы, буду песать еще :)

gserg ★★
() автор топика

"Сигналы SIGKILL и SIGSTOP невозможно не перехватить, не игнорировать."

ни перехватить, ни игнорировать.

the_one
()

спасибо, полу-методички тоже хороши!!

kbps ★★★
()

Сколько ни читаю статей про процессы в UNIX, никак не мог понять зачем при fork()'е копируется весь родительский процесс, ведь это так неэкономично. Если "тяжелому" процессу нужно породить "легкий", зачем нужно копировать себя в своей тяжелости?

anonymous
()
Ответ на: комментарий от anonymous

>Сколько ни читаю статей про процессы в UNIX, никак не мог понять зачем при fork()'е копируется весь родительский процесс, ведь это так неэкономично. Если "тяжелому" процессу нужно породить "легкий", заче нужно копировать себя в своей тяжелости?

В системах, соответствующих SVR4 код и данные процесса загружаются в память только при необходимости. То есть при выполнении fork() в памяти оказывается код только нового процесса и той функции старого, в которой выполняется exec()

gserg ★★
() автор топика
Ответ на: комментарий от the_one

> "Сигналы SIGKILL и SIGSTOP невозможно не перехватить, не игнорировать."

> ни перехватить, ни игнорировать.

Рассказываю. Есть у меня компакт-диск. Вставляю. Делаю

dd if=/dev/cdrom of=/dev/null

Отжирает 100%

Не убиваеццо ни kill -TERM, ни kill -KILL

Приходится перегружать всю систему. Проверял на разных приводах и ядрах.

Ась?

Spinal
()

Мне кажется или тут опечатка?
=========================================
chmod u+s filename – установка бита SUID

chmod u+s filename – установка бита SGID
=========================================

Spinal
()

Отличный баланс информации, ничего лишнего. Проврено на женщине с контрольными вопросами.

anonymous
()
Ответ на: комментарий от Atlant

>Да не копирует он себя, ни разу!

"Создание процесса – на этом этапе создается полная копия того процесса, который создает новый." Нужно поправить тогда.

anonymous
()

Не читал, но одобряю. Шрифт листингов лучше изменить, а то глаза выпадают.

mutronix ★★★★
()
Ответ на: комментарий от Spinal

> Не убиваеццо ни kill -TERM, ни kill -KILL Приходится перегружать всю систему. Проверял на разных приводах и ядрах. Ась?

в принципе это можно рассматривать как баг ядра: процесс сделал системный вызов, а этот вызов заклинило в непрерываемом состоянии

dilmah ★★★★★
()
Ответ на: комментарий от gserg

> при выполнении fork() в памяти оказывается код только нового процесса и той функции старого, в которой выполняется exec()

про ту функцию старого ты что-то не то отжег:)

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

Почитал я про copy-on-write, как понял, при fork()'е передается поинтер на область памяти родителя, а копируется он только тогда когда нужно делать write (exec()). Но это все-равно идиотизмъ! :) Я не могу понять логики. Почему бы не создать процесс "просто", без дурацкого fork-exec? :)

anonymous
()
Ответ на: комментарий от Spinal

Разбавляй бензин ослиной мочей. Если после этого твоя машина не заведётся - значит ты плохой водитель.

frame ★★★
()
Ответ на: комментарий от anonymous

> Но это все-равно идиотизмъ! :) Я не могу понять логики. Почему бы не создать процесс "просто", без дурацкого fork-exec? :)

видимо, потому что тут руководствовались алгебраической красотой дизайна -- форк и екзек это ортогональные операции которые позволяют процессам жить полноценной жизнью. А оверхед несущественен на процессорах с MMU

dilmah ★★★★★
()
Ответ на: комментарий от Spinal

>>Рассказываю. Есть у меня компакт-диск. Вставляю. Делаю

>>dd if=/dev/cdrom of=/dev/null

>>Отжирает 100%

>>Не убиваеццо ни kill -TERM, ни kill -KILL

1.У тебя диск царапаный и/или привод нехороший.

2.Процесс нельзя убить даже TERMом если он находится в Uninterruptible sleep

Nao ★★★★★
()
Ответ на: комментарий от Nao

> 2.Процесс нельзя убить даже TERMом если он находится в Uninterruptible sleep

Видимо, s/TERM/KILL/. От TERM'а любой процесс убежать может.

Отсюда вопрос: а что с ними делать-то?? А то вот было у меня: прицепил cifs, потом сервер исчез... все процессы, что туда смотрели, повесились в disk sleep. Есть ли способ убрать такой нехороший процесс?

const86 ★★★★★
()
Ответ на: комментарий от dilmah

> это как раз для встраиваемой техники без MMU

Ну да, в мане по vfork написано, что для таких случаев оно и придумывалось. Там же сказано, что на полноценных архитектурах этот выпендрёж просто не нужен и fork ничуть не хуже.

const86 ★★★★★
()
Ответ на: комментарий от const86

const86:

> ...на полноценных архитектурах этот выпендрёж просто не нужен и fork ничуть не хуже.

Не так.

Самая тяжелая операция при форке -- пометить страницы для COW. vfork этого не делает, о чем, кстати, в мануале по vfork ясно написано.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Самая тяжелая операция при форке -- пометить страницы для COW.

"...so the __only__ penalty incurred by fork() is the time and memory required to duplicate the parent's page tables..."

Действительно, самая тяжёлая операция. Но это не то, из-за чего придумывался vfork :) Всё равно его не рекомендуется использовать. Или fork, или posix_spawn.

const86 ★★★★★
()
Ответ на: комментарий от const86

const86:

> Но это не то, из-за чего придумывался vfork :)

Придумывался он до изобретения COW, действительно. Но в "современных операционках" разница между fork и vfork _существенна_: разница в скорости составляет многие разы, иногда сотни и тысячи раз.

Если из многогигабайтного процесса надо много раз запустить новый легкий процесс, использование vfork очень даже оправданно.

А posix_spawn -- ADVANCED REALTIME экзотика и используется совсем не для этого; ее придумали в первую очередь для того, чтобы запускать процессы в системах, не поддерживающих страничный механизм.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Вы таки можете новайсу объяснить что реально происходит при {v,}fork{}? :)

anonymous
()

> SIGSTOP >Остановить >Сигнал отправляется всем процессам текущей группы при нажатии пользователем клавиш <CTRL>+<Z>. Получение сигнала вызывает останов выполнения процесса.

Придираюсь, конечно... При нажатии <CTRL>+<Z> посылается SIGTSTP, а не SIGSTOP.

anonymous
()
Ответ на: комментарий от Spinal

Да, не мешало бы поправить в строчке "chmod u+s filename - установка бита SGID"...

:s/u+s/g+s/g

putpixel
()
Ответ на: комментарий от xtron

>С авторами сайта как связатся можно ? Че-то никаких контактов не нашел.

Через ЖЖ - там есть ссылка

gserg ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.