Первоначально сеть использовалась для передачи данных из одной машины в другую. Позже она развилась, давая возможность пользователям удаленно регистрироваться на другой машине. Следующим логическим шагом было перемещение данных к пользователю, вместо необходимости пользователю идти к данным - так родились сетевые файловые системы. Пользователи, работающие локально, не подвергаются сетевым задержкам при каждом нажатии на клавишу, таким образом они имеют более отзывчивое окружение.
Доставка файловой системы на локальную машину была первой из главных клиент-серверных приложений. Сервер является удаленной машиной, экспортирующей одну или более из своих файловых систем. Клиент является локальной машиной, импортирующей эти файловые системы. С точки зрения локального клиента смонтированная удаленная файловая система выглядит в пространстве имен дерева файлов точно так же, как любая другая локально смонтированная файловая система. Локальные клиенты могут переходить по каталогам удаленной файловой системы и могут читать, записывать и исполнять двоичные файлы внутри этой удаленной файловой системы таким же способом, как они могут делать эти операции на локальной файловой системе.
Когда локальный клиент выполняет операцию на удаленной файловой системе, запрос упаковывается и посылается серверу. Сервер выполняет запрошенную операцию и возвращает либо запрошенную информацию, либо ошибку, указывающую, почему запрос был отклонен. Для обеспечения приемлемой производительности клиент должен кешировать данные, к которым осуществляется частый доступ. Сложность удаленной файловой системы заключается в поддержании согласованности кеша между сервером и множеством клиентов.
Хотя с течением времени было разработано много протоколов удаленных файловых систем, наиболее распространенным в системах UNIX является Network Filesystem (NFS), протокол и наиболее широко использующаяся реализация которой были выполнены фирмой Sun Microsystems. Ядро FreeBSD поддерживает протокол NFS, хотя реализация была сделана независимо от спецификации протокола [Macklem, 1994].
Большинство действий, связанных с доставкой сигнала потоку, выполняется в контексте этого потока. Поток проверяет свое поле td_siglist на предмет наличия ожидающих сигналов по крайней мере один раз при входе в систему, вызывая cursigQ.
SLEEPING - Поток заблокирован в ожидании события. Если поток находится в состоянии непрерываемого сна, больше ничего не должно предприниматься. В противном случае ядро может предпринять действие - либо непосредственно, либо косвенно, - пробудив поток. Есть два действия, которые можно применить непосредственно. Для сигналов, вызывающих остановку процесса, все потоки в процессе помещаются в состояние STOPPED и родительский процесс уведомляется об изменении состояния посредством отправки ему сигнала SIGCHLD.
Реализация сигналов разделена на две части, первая из которых - отправка сигнала процессу, а вторая - распознавание сигнала и доставка его потоку назначения. Сигналы может отправлять любой процесс или код, который выполняется на уровне прерывания. Доставка сигнала обычно имеет место в контексте получающего потока. Но когда сигнал форсирует остановку процесса, действие может быть проведено для всех потоков, связанных с этим процессом в тот момент, когда сигнал был отправлен.
Сигналы первоначально были спроектированы для моделирования исключительных событий, таких, как попытка пользователя завершить вышедшую из-под контроля программу. Они не предназначались для использования в качестве общего механизма межпроцессного взаимодействия, поэтому не было сделано попытки сделать их надежными. В более ранних системах каждый раз при перехвате сигнала восстанавливалось его действие по умолчанию.
Описание сигналов указывается для каждого процесса. Если процесс не указал действие на сигнал, ему предоставляется действие по умолчанию которое может быть одним из следующих: