Если Вы не хотите беспокоиться этим, сделайте это как я:
SigLevel = Optional TrustAll
$ ps -eLf
UID PID PPID LWP C NLWP STIME TTY TIME CMD
root 1 0 1 0 1 19:25 ? 00:00:00 init [4]
...
root 1699 1 1699 0 1 19:25 ? 00:00:00 /usr/bin/kdm
root 1701 1699 1701 8 2 19:25 tty10 00:13:10 /usr/bin/X :1 vt10 ...
root 1701 1699 1703 0 2 19:25 tty10 00:00:00 /usr/bin/X :1 vt10 ...
root 1706 1699 1706 0 1 19:25 ? 00:00:00 -:1
root 1707 1699 1707 0 2 19:25 tty9 00:00:02 /usr/bin/X :0 vt9 ...
root 1707 1699 1710 0 2 19:25 tty9 00:00:00 /usr/bin/X :0 vt9 ...
root 1713 1699 1713 0 1 19:25 ? 00:00:00 -:0
....
отвечает на Ваш вопрос, я думаю.
Тем не менее, вопрос, кажется, смешивает несколько вещей - многопоточность не о не использовании fork()
/exec()
. Потоки совместно используют то же адресное пространство и если Вы хотите выполнить другой процесс, Вы, конечно, не хотите, чтобы оно имело доступ к тому же адресному пространству. И если Вы решили не использовать внешние программы (особенно в оболочке, что, так как Вы упоминаете это), необходимо было бы кодировать всю функциональность снова.
Многопоточность не является средством исправления для всего. Это может главным образом быть средство исправления только для хорошо parallelizable проблем на самом деле - проверяют страницу Wiki на хороший краткий обзор. Создание многопоточной программы не делает его лучше, в большинстве случаев это делает это хуже из-за ошибок в коде синхронизации (если существующий вообще).
Насколько я понимаю ничто о самом X11 не предотвращает многопоточные клиенты, это просто, что Xlib имеет некоторые условия состязания, которые просто не могут быть устранены. Я беру это от XCB, я не знаю на основе опыта. XCB является библиотекой Xlib-слоя, разработанной, чтобы использоваться с многопоточными клиентами. Так, похоже, что клиенты X11 склонны быть записанными как событийно-ориентированные программы псевдореального времени просто так. Нет никакой причины не сделать поточные клиенты.
В книге Е. С. Рэймонда автор цитаты.
X Server, способный выполнить буквально миллионы OPS / второе, не резьба; Он использует петлю опроса / выбора. Различные усилия по внесению многопотативной реализации пришли к хорошему результату. Расходы на блокировку и разблокировку слишком высоки для чего-то в качестве чувствительных к производительности в качестве графических серверов. - Джим Геттис
Это не прямой ответ на вопрос, но я чувствую, что он проясняет ситуацию, и он слишком длинный для комментария.
Я думаю, вам не следует сравнивать потоки UNIX с процессами(fork()
). Этот вопрос, кажется, предполагает, что потоки каким-то образом заменяют процессы, что неверно.Оба они имеют свои преимущества и недостатки, и, в конечном счете, решение о том, что использовать, если таковое имеется, остается за программистом. То же самое касается повторной реализации.
Если бы было преимущество использования потоков, базовые инструменты были бы реализованы заново или, по крайней мере, была бы вилка, нацеленная на это.
Лично я считаю, что для такой задачи, как оболочка, многопроцессорная обработка является лучшей альтернативой, так как вы получаете надежную защиту для своей оболочки :процессы, которые она запускает, могут выйти из-под контроля, но она не остановит оболочку.
С другой стороны, т.е. сигналы доставляются во все потоки, поэтому многопоточная оболочка должна быть в состоянии пережить сигналы, которые нацелены на/создаются потоками утилиты, и в то же время доставлять эти сигналы, потому что потоки утилиты могут нуждаться в них...
Все -в -все :многопроцессорность позволяет лучше разделить оболочку и процессы, которые она запускает, и дает больше свободы процессам, запущенным оболочкой, чтобы иметь сигналы, и, возможно, кучу других вещей I не могу думать.
ps
ответить на мой вопрос? – hruvulum 08.06.2013, 19:13