LINUX.ORG.RU

Потокобезопасность system(3) в glibc

 , , , ,


0

1

При чтении документации glibc обнаружил, что system(3) заявлена как потокобезопасная. Что противоречит интуитивно ожидаемому: функция манипулирует обработчиками сигналов, следовательно должна быть MT-Unsafe. Это побудило подробнее изучить вопрос и сравнить реализации в разных ОС.

Возможно пригодится кому:

Ответ на: комментарий от wandrien

… а musl мне никогда не нравилась, особенно, после статьи, в которой описывалось, как запросы в mysql под musl работали на одинаковом датасете не таким же образом, как на glibc.

После этого, наверняка, был какой-то фикс в либу, но ложечки, как говорится, нашлись, а осадочек остался. Поделка какая-то. Хоть и маленькая, но поделка.

aol ★★★★★ ()

Так что я зарепортил баг относительно лакуны в документации musl:

https://github.com/somasis/musl-wiki/issues/63

Красавец, теперь зарепорть не в рандомный багтрекер, а в список рассылки musl, как потребовано.

Самый большой грех system в том, что она не ищет в $PATH. Следующий — в том, что шеллы там у всех разные. Третий по величине — что создаёт круговую зависимость между шеллом и libc. Не юзайте эту дрянь.

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

Красавец, теперь зарепорть не в рандомный багтрекер

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

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

http://musl.libc.org/support.html

musl has a single mailing list for development discussion and user support. Questions and comments related to compiling musl, compiling software against musl, porting, bugs, differences between musl and glibc or other libc implementations, feature requests, etc. are all on-topic and welcome.

Теперь давай свой пруф.

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

https://wiki.musl-libc.org/

You can contribute to this wiki! Submit pull-requests to somasis/musl-wiki.

А по сути, дурак ты и не лечишься. Нормальные люди либо сотрудничают при наличии общего интереса, либо просто не трогают друг друга. Тебе же нужно до всех докопаться с какой-то хернёй.

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

Чел, ты проиграл, это community wiki, а ни разу не обещанная тобой ссылка с официального сайта. Если у тебя была цель поныть в месте, чуть релевантнее ЛОРа, то ты, конечно преуспел. Но лучше зарепорть баг как полагается.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 4)
Ответ на: комментарий от wandrien

зачем ты так много внимания уделяешь работе софта на других системах *nix? все эти системы фактически давно мертвы, только линукс остался

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

Самый большой грех system в том, что она не ищет в $PATH. Следующий — в том, что шеллы там у всех разные. Третий по величине — что создаёт круговую зависимость между шеллом и libc. Не юзайте эту дрянь.

Ерунда от начала до конца. system вызывает /bin/sh -c «аргумент». Соответственно, в $PATH ему искать нечего. /bin/sh задан уже с путём (и там должен быть posix shell а не разное у всех), а аргумент - это команда для шелла, интерпретирует её шелл а не system. И зависимости никакой нет.

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

Ерунда от начала до конца. system вызывает /bin/sh -c "аргумент".

Да. Путь к бинарнику везде константа, и нет никакого смысла использовать там $PATH.

Пойнт про то, что шеллы везде разные, тоже нерелевантен. На POSIX-совместимой системе шелл должен быть POSIX-совместимым. А на несовместимой, извините, как получится. В DOS это COMMAND.COM, в винде при использовании нативного рантайма от MSVC это CMD.EXE.

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

Ерунда от начала до конца. system вызывает /bin/sh -c «аргумент». Соответственно, в $PATH ему искать нечего. /bin/sh задан уже с путём (…), а аргумент - это команда для шелла, интерпретирует её шелл а не system.

Ну, это ясное дело.

И зависимости никакой нет.

Есть. Нет /bin/sh — твой system сломан. => libc зависит от шелла

и там должен быть

Не должен, все well-known пути — зло.

posix shell а не разное у всех

В Alpine — ash, в Debian — dash, в Fedora — bash…

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

Путь к бинарнику везде константа

Да. Благодаря этому историческом идиотизму я могу одновременно юзать сколько угодно libc, но шелл для system это теперь святое и единое для всех.

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

Благодаря этому историческом идиотизму я могу одновременно юзать сколько угодно libc, но шелл для system это теперь святое и единое для всех.

Если ты можешь юзать разный libc, то и константу в нём при компиляции на свою заменить можешь.

/thread

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

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

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

Это все несовместимый по-разному бажный POSIX Shell

Репорти. Отклонения от швятой бумаги должны фиксить.

который больше не заморозить средствами пакетного менеджера.

Не распарсил.

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

Есть. Нет /bin/sh — твой system сломан. => libc зависит от шелла

Нет. Он не сломается, он штатным образом будет отдавать ошибку. Точно так же как open(«/non-exist/1/2/3») тоже выдаст ошибку, но не от того, что сломан open() а от того, что он должен выдавать ошибку при попытке открыть несуществующий путь.

В Alpine — ash, в Debian — dash, в Fedora — bash…

Это разные реализации одного и того же. Но вообще это всё не суть. system(arg) это алиас к fork()+exec(«/bin/sh»,"-c",arg)+wait(). И именно в этом его назначение. /bin/sh это просто строка, передаваемая системному вызову execve(), в состав спецификации libc спецификация шелла не входит.

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

Что ты вообще такое делаешь через несчастную system(3), что у тебя лезут баги шеллов? Единственное полезное её предназначение это запустить скрипт в более другом шелле.

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

Я могу написать nix run… и получить произвольное окружение с любым набором софта любых версий на любой момент времени. Кроме ядра, потому что сложно на лету сменить ядро, и, блин, драного /bin/sh, потому что см выше, что я о них думаю.

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

А я и меняю

Зачем?

безо всякой хорошей на то причины.

Причина очень простая - дать простой проге на си короткий, в одну команду, способ запуска команд шелла, когда программист хочет просто по-быстрому запустить команду и ни о чём не думать. Такое использование си в качестве скриптоязыка. Если прога сложная, то там system() вряд ли будет использоваться, почти наверняка будет использоваться кастомная конструкция из fork+execve+wait и ещё кучи функций в середине, которые в system никак не вставить.

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

system() — это самый минимальный интерфейс к вызову команд операционной системы, предусмотренный для hosted-реализации Си.

Он даже потоки ввода-вывода не описывает, потому что в ОС может не быть поддержки потоков. Может даже и самого шелла не быть.

Ты от него слишком много хочешь.

Для Unix-like системы в твоём распоряжении всегда есть нормальные exec() и posix_spawn().

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

Он не сломается, он штатным образом будет отдавать ошибку.

Ака сломается.

system(arg) это алиас к fork()+exec(«/bin/sh»,«-c»,arg)+wait(). И именно в этом его назначение. /bin/sh это просто строка, передаваемая системному вызову execve(), в состав спецификации libc спецификация шелла не входит.

А должен был быть к execlp или как его там и искать sh в $PATH.

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

Зачем?

Потому что в моем дистрибутиве не будет драного /bin/sh или драного /usr/bin/env. Все well-known пути должны отмереть, потому что без этого я не могу (без танцев вприсядку) иметь их разными для разных процессов, а значит не могу иметь и воспроизводимости.

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

Еще интерпретатор ELF-файлов забыл.

Это в обычном лине чуть меньше.

А в никсе где всё линкуется по путям вида a54d010860b3e9c4b8c9c282e61da5b7128c7547697151aaca36ee771d323dc9/lib/libmycoollib.so их чутка больше.

Да, и еще тебя ждёт чудовищное открытие. Все дефолтные пути к юникс-сокетам типовых сервисов (иксы, вялый, пульса, систымдэ…) - захардкожены1111адынадын

Кстати, я как раз либу вон щас пишу: https://github.com/sde-gui/libmypath

Задрал софт с захардкоженными путями в собственным дата-файлам. У меня в SDE уже было это пофикшено иным способом, но там слишком complicated. Надо проще и дубовее.

wandrien ()
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от wandrien

Еще интерпретатор ELF-файлов забыл.

Нет ты. Интерпретатор ELF-файлов не обязал лежать по well-known пути. И в NixOS по нему и не лежит. Даже, блин, он не обязан, зато драный /bin/sh вынь да положь.

А в никсе их больше

А в никсе они как раз 100% сменные. Настолько, что меняются на каждый чих полностью прозрачно для тебя. Но ты и так в курсе, просто неумело троллишь.

Да, и еще тебя ждёт чудовищное открытие. Все дефолтные пути к юникс-сокетам типовых сервисов (иксы, вялый, пульса, систымдэ…) - захаржкожены1111адынадын

Тоже мне открытие.

On Unix systems, there’s no reliable way for an application to retrieve a path to its own executable image or any other application-related files.

Эээ, у тебя есть libc, поддерживающая работу без /proc? Потому что dynamic loader зависит от /proc/self/exe, инфа 100%

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

Нет. Это не способ создавать процессы вообще. Процессы есть не везде. Реализация в юниксах - через создание процесса, да. Ну а так есть стандартное fork() для создания нового процесса.

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

Эээ, у тебя есть libc, поддерживающая работу без /proc? Потому что dynamic loader зависит от /proc/self/exe, инфа 100%

No idea. Я не тестировал весь зоопарк Unix-like. Что за линукс-центризм?

Но ты и так в курсе, просто неумело троллишь.

Нет ты. (с)

Если ты можешь пропатчить всё. (А в nix ты реально патчишь кучу всего при сборке - как минимум, прописываешь тьмущу констант), то точно так же ты можешь пропатчить путь к sh.

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

А в никсе они как раз 100% сменные.

Он прописан в бинарнике каждом в заголовке. Как шебанг для скриптов.

Эээ, у тебя есть libc, поддерживающая работу без /proc?

В FreeBSD /proc deprecated и по дефолту даже не монтируется.

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

Что за линукс-центризм?

Ясно. Ну, короче для Linux твоя задача звучит странно, потому что мы и так сидим на крепкой игле /proc.

Если ты можешь пропатчить всё. (А в nix ты реально патчишь кучу всего при сборке - как минимум, прописываешь тьмущу констант), то точно так же ты можешь пропатчить путь к sh.

Так я и патчу, и нарушаю POSIX.

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

Он прописан в бинарнике каждом в заголовке. Как шебанг для скриптов.

Ну, и легко меняется штатными средствами ПМ. Или ты хочешь единые бинарники носить между системами без зависимостей как в какой-то винде? Тогда да, ты в пролёте, носить их без остального closure не выйдет.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Или ты хочешь единые бинарники носить между системами без зависимостей как в какой-то винде? Тогда да, ты в пролёте, носить их без остального closure не выйдет.

А я хочу.

Я настолько обнаглел, что хочу носить бинарники между Linux и BSD-зоопарком.

и легко (и постоянно) меняется штатными средствами ПМ.

И о чем плачь Ярославны тогда?

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

Он не стандартный для СИ

Это к чему? В стандартной библиотеке Си вообще нет понятия процессов. Процессы есть в POSIX, там же есть и функции для работы с ними.

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

Я настолько обнаглел, что хочу носить бинарники между Linux и BSD-зоопарком.

Носи виртуалки, ты же любитель всяких контейнеров и прочих тяжёлых решений там, где не надо.

И о чем плачь Ярославны тогда?

Мой — о /bin/sh, который даже в NixOS захардкожен из-за драного POSIX.

Ваш — о dynamic loader’е, с которым как раз никаких проблем нет. Я тоже не знаю, зачем вы его затянули.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)