Почему семафоры не являются объектами файловой системы?

а потом какая нибудь левая программа попытается открыть твой заблокированный "семафорный файл" и повиснет :)

Если читать из пустого пайпа - тоже повиснешь

Левая программа тебе rm -rf ~ сделает. В этом отношении, имхо, mknod, mksock и mkfifo ничем не отличаются.

А если программа выставила семафор и подохла, как его закрыть?

Lock файл я могу и удалить руками.

>А если программа выставила семафор и подохла, как его закрыть?

Как и во всех остальных случаях, всё закрывается само.

PS Семафоры (именованные) сейчас являются глобальными объектами.

Зачем нужен mksem, если есть flock?

>Lock файл я могу и удалить руками.

А как ты пользуешься локами?

[ -e /var/lock/sin_a.lock ] && exit 1

touch /var/lock/sin_a.lock

Так? А о race condition ты слышал?

>Зачем нужен mksem, если есть flock?

Как вызвать флок из шелл-скрипта?

man 1 flock

>man 1 flock

Блин, не знал. Спасибо. Ладно, частный вопрос со скриптами закрыт. Остался общий: почему семафоры не являются объектами файловой системы как fifo и прочее?

> почему семафоры не являются объектами файловой системы как fifo и прочее?

Потому что их реализовывал другой отдел.

>Потому что их реализовывал другой отдел.

Microsoft Synchronization Lab?

>> Потому что их реализовывал другой отдел.

> Microsoft Synchronization Lab?

Indian Hill Facility.

> Остался общий: почему семафоры не являются объектами файловой системы как fifo и прочее?

Мне почему-то кажется, что на этом форуме нету людей, которые разрабатывали семафоры SystemV и/или POSIX. Такой ответ тебя удовлетворит?

Ээээ?? А что же тогда появляется в /dev/shm/?

> Ээээ?? А что же тогда появляется в /dev/shm/?

Есть XSI-семафоры и realtime-семафоры. Тот факт, что вторые живут в /dev/shm и что они представлены именно файлами - особенности реализации (glibc), их могло бы там и не быть. А первые и вовсе никаким ls'ом не увидишь.

> Пайпы, например, являются. Почему семафоры нет?

Интерфейс XSI (aka SysV IPC) вообще выглядит как-то "не так". Похоже, его и правда разрабатывал какой-то другой отдел :)

В довесок можно спросить: а почему сетевые интерфейсы не являются файлами? В некоторых ОС являются, но от этого не легче. Общение с интерфейсом всё равно идёт через фиктивный сокет, а не через read/write/ioctl девайса.

С другой стороны, перегибать палку тоже не надо. Вот например: UNIX-сокеты являются файлами (необязательно). А зачем??

Чтобы права на них ставит и читать-писать через coreutils, дурилка.

> Чтобы права на них ставит и читать-писать через coreutils, дурилка.

Это про UNIX-сокеты? Нехорошо я выразился... Читать-писать в сокет, как в файл - это конечно здорово. Парадокс в том, что сокеты живут на файловой системе, то бишь на диске. И сокет остаётся жить даже после завершения процесса, который его слушал. Хотя единственное разумное, что с ним можно сделать тогда - unlink. В общем, я не хочу сказать, что это совсем плохая идея, но какая-то недодуманность просматривается.

>какая-то недодуманность просматривается.

Да, но с другой стороны если создавать именованные объекты в некотором "астрале" (как в оффтопике), то для операций с ними (в частности для контроля доступа) приходится вводить дополнительные велосипедистые системные вызовы.

> Блин, не знал. Спасибо. Ладно, частный вопрос со скриптами закрыт.

только flock(1) нестандартный. В БСД его место занимает shlock(1)

Блджад, почему нельзя было уже стандартизировать хотя бы это?

> Блджад, почему нельзя было уже стандартизировать хотя бы это?

К сожалению, и в посиксе есть белые пятна. Вот например, утилита setsid, которая есть в пакете util-linux. Да ещё море примеров можно вспомнить...