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

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

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

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

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

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

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

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

Но может с 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++);

Эх, ну pthreads так pthreads.

Код хардкорный, не поспоришь)

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

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

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

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

А что не так с первым куском кода? Если не выдирать из контекста, то код на самом деле весьма адекватен.

http://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n567

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

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

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

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

Хотел посмотреть, если ли прогресс, но нет:

https://sourceware.org/bugzilla/show_bug.cgi?id=14092

Либо удивительно наплевательское отношение, либо «политика».

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

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

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

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

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

Понял. Благодарю

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

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

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

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

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

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

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

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

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

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

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

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

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

даже

в солярке

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

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

а ты смешной

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

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

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

капитан?

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

#ifdef HAVE_THREADS_H
# include <threads.h>
#else
# include "tinycthread.h"
#endif

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

Ого. Даже на винде работает

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

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

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

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

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

Мы не знаем точно, что сейчас в ядре солярки.

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

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

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

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

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

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

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

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

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

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