LINUX.ORG.RU

pthreads, С11 threads, musl и зависимые от glibc либы

 , , ,


0

4

Здравствуйте. Это будет сумбурный вопрос. И такое же изложение. Простите

Я не разбираюсь в потоках. Внезапно понадобились. Ознакомился поверхностно. Есть pthreads и C11 threads. C11 конечно звучит более модно интересно. Но glibc их не умеет. Зато их умеет musl.

Ок. Предположим, я компилирую свой код с musl. Но мне так-же хочется использовать hiredis, у которого в зависимостях glibc..

И вот тут я поломался. Знаний мало. Нет полной картины что будет в этой ситуации. Подскажите, будте так любезны.

Что будет если я компиляю свой код с musl и подключаю либы у которых glibc в зависимостях?

★★★★★

Уф... Давай ты просто сделаешь man pthreads, почитаешь, будешь умничкой, и все через них сделаешь, мм?

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

Чую так и придется сделать. Но может с musl всё проще чем мне кажется. Тогда почему бы и не заюзать threads.h )

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

Если использовать будешь только musl, то делай что хочешь.

Если софтина делается под некий «generic linux», то pthread без вариантов.

А вообще не выпендривайся и бери pthread.

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

А вообще не выпендривайся и бери pthread

Это я уже понял) Но все-таки, что будет если компилять с musl и подключать зависимые от glibc либы?

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

Но может с musl всё проще чем мне кажется.

Загрузка/линковка двух libc в один процесс ни к чему хорошему не приведёт (на SO), при везении оно даже не сразу упадёт, но рано или поздно это произойдёт. Реализации libc предполагают, что все функции/данные их и если одна libc получит данные от другой, то быть беде.

Тогда почему бы и не заюзать threads.h )

Там похоже лишь косметические изменения по сравнению с pthreads, в том же musl практически всё просто заворачивается на pthreads.

Общий совет: использовать glibc, а не musl. Я знаю исходники musl и как-то не доверяю людям, которые говорят, что у них мега-читабельные исходники, а у glibc всё сложно, а сами пишут такое:

			if (0) {
		case 'o':
			a = fmt_o(arg.i, z);
			if ((fl&ALT_FORM) && p<z-a+1) p=z-a+1;
			} if (0) {
		case 'd': case 'i':
	if (((uintptr_t)s & ALIGN) == ((uintptr_t)d & ALIGN)) {
		for (; ((uintptr_t)s & ALIGN) && n && (*d=*s)!=c; n--, s++, d++);
		if ((uintptr_t)s & ALIGN) goto tail;
		k = ONES * c;
		wd=(void *)d; ws=(const void *)s;
		for (; n>=sizeof(size_t) && !HASZERO(*ws^k);
		       n-=sizeof(size_t), ws++, wd++) *wd = *ws;
		d=(void *)wd; s=(const void *)ws;
	}
	for (; n && (*d=*s)!=c; n--, s++, d++);
У glibc также намного больше тестов.

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

Вообще, вот есть заголовок для стандартных потоков на pthreads хоть для glibc, хоть для чего-то другого, где есть pthreads. Разбить это на два файла тривиальная задача. Не уверен на счёт полноты замены, но о неполноте там не написано, так что должно быть нормально.

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

Ух-ты. Прям как polyfill в js. Поизучаю

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

Низзя так. Что-то одно. Если интересует этот вопрос - глянь в грязные хаки apkenv и libhybris. Там грузят 2 разных libc. Замечу, что у меня только apkenv заработал, а libhybris так и не завёл.

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

Если тебе удастся написать стабильный загрузчик glibc - сообщи. Пригодится в xash3d.

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

Я просто сначала подумал что если gcc подсунуть musl, то hiredis волшебным образом подхватит его вместо glibc. А потом вспомнил, что это си, а не питон)

Хотя, с другой стороны, какая линкеру разница в какую либу символы резолвить. Что мешает подменить скомпиленной либе glibc на musl?

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

Прыжки в середину и обход вокруг if (0) это то ещё извращение. Можно ведь было вынести это ниже и сделать не такими jump'ами. Или хотя бы goto уже использовать для обхода if ради единообразия с case. Там и по выравниванию особо не видно как идёт исполнение (там же несколько if-ов подрят и несколько меток во всех возможных местах относительно их). Я когда этот участок первый раз увидел, хотел снести лишние выражения, но потом понял, что это не ошибка.

xaizek ★★★★★
()

с чего ты решил использовать musl? он тебе может понадобиться только если ты собираешь какой-то жосский эмбеддед и там требования к оптимизации по объёму и памяти очень высоки. с потоками во всех этих эмбеддед библиотеках всё по-разному и оно чаще всего не совместимо со стандартным линюксовым общепринятым libc. так что не создавай себе геморроя на ровном месте, если ты явно не понимаешь, что без musl тебе не собрать образ нужного размера, например. в общем случае используй libc и pthreads.

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

Например, разный вид структур в системных функциях.

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

Хотя, с другой стороны, какая линкеру разница в какую либу символы резолвить. Что мешает подменить скомпиленной либе glibc на musl?

Но линкер не из воздуха берет информацию о том, какие символы ему нужны, а из исходников. Исходники, которые пишешь именно ты, как правило, только используют символы из какого-то API, но не объявляют их. Объявления в твоих исходниках появятся из хедеров библиотек. А они уже могут (и будут!) содержать детали реализации библиотеки — хоть стандартной, хоть нет. Например, ссылаться на какие-то внутренние символы библиотеки. В итоге еще на этапе трансляции, еще до линковки, ты уже завяжешься на кишки используемой реализации. Короче, линкеру есть разница, в какую либу символы резолвить, потому что попросту набор символов может различаться.

Ну и тут выше сказали про вид структур. Это всё о том, что в общем случае библиотеки с совпадающим API не обязаны иметь одинаковое ABI.

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

Вообще-то pthreads в glibc реализованы просто ужасно - в частности невозможно управлять приоритетом потоков, кроме того потоки рассматриваются как отдельные процессы. Однако для несложных проектов pthreads вполне можно использовать под линуксом.

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

Вообще-то pthreads в glibc реализованы просто ужасно

Что же делать тогда?

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

с чего ты решил использовать musl?

А чего в glibc до сих пор 11 тредов не завезли? 5 лет уже прошло

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

кроме того потоки рассматриваются как отдельные процессы

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

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

gentoo с musl собирают, дебиан емнип тоже

мюсли нынче общего назначения

ну хотя мой опыт основан на картинках

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

Есть мнение, что должен быть гибрид kernel threads и userspace threads, загугли «m:n thread model» или «m:n multithreading».

PS. Это лишь к слову. По поводу качества pthreads в glibc ничего сказать не могу.

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

От m:n отказались даже в солярке, в BSD не осилили с многопроцессорными системами, а в линуксе пилят попсу, и такие вещи не реализуют никогда.

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

Вообще, говорят, что лучшая реализация потоков в dragonflybsd.

даже

в солярке

ну толсто же! А солярка сама по себе в последнее время всё меньше проприетарный крап^W UNIX и всё больше линукс.

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

Вообще-то pthreads в glibc реализованы просто ужасно - в частности невозможно управлять приоритетом потоков

а ты смешной

http://man7.org/linux/man-pages/man3/pthread_setschedparam.3.html

кроме того потоки рассматриваются как отдельные процессы

дурачок - это особенность ядра а не glibc

anonymous
()

Я сейчас если не использую glib, то пользуюсь https://tinycthread.github.io/ . Полноценный API C11 threads.h через pthreads или WinAPI. Если написать что-то типа:

#ifdef HAVE_THREADS_H
# include <threads.h>
#else
# include "tinycthread.h"
#endif
будет работать одинаково и при наличии и при отсутствии C11 threads.

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

что толсто? линакс как был догоняющим, в технологическом плане, так и остаётся набором костылей и подпорок скреплённых соплями с изолентой.

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

Если не считать пары отдельных технологий, реализованных изначально в ядрах других систем, у линуксов вроде количество новых сырых (в том числе не работающих/работающих не всегда и не везде) фич значительно выше, чем у конкурентов.

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

Если не считать пары отдельных технологий, реализованных изначально в ядрах других систем

Это каких и откуда, не просветишь? Так-то у линукса вообще ничего своего нет, всё откуда-то потырено получается.

у линуксов вроде
вроде
не работающих/работающих не всегда и не везде

Что я и написал в первом каменте про изоленту, в этом вся суть линуксов.

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

Я вру. PaX и Exec Shield были в линуксе за годы до реализации подобных технологий у конкурентов. Мне почему-то казалось, что всё это перетянули откуда-то из UNIX'ов и UNIX-like.

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

Можно почитать ченджлог релизов, чтобы получить общее представление.

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

PaX и Exec Shield были в линуксе за годы до реализации подобных технологий у конкурентов

У конкурента оно уже было в 90х вместе с rbac и mac.

Мне почему-то казалось, что всё это перетянули откуда-то из UNIX'ов и UNIX-like.

Оно так и есть. И да, в ядре-то этот pax когда появится, а то что это за продакшн такой наколенный.

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

а чем pthreads плох? вполне себе позиксовский. видимо, потому и не завезли, что как-то не нужно никому было. всё равно в С нет кроссплатформенности искаропки, для чего-либо более-менее серьёзного. а раз потоки - функциональность системы, то вообще нелогично её тащить в стандарт.

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

а раз потоки - функциональность системы, то вообще нелогично её тащить в стандарт

Но ведь притащили зачем-то..

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.