Библиотека для многопоточности

pthreads

с языка снял

Я не хочу сложностей на винде.

Я не хочу сложностей на винде.

https://sourceware.org/pthreads-win32/ - использовал для портирования одной штуки с линукса много лет назад, не помню чтобы возникли какие-то проблемы.

https://github.com/apache/apr

на те враппер https://github.com/tinycthread/tinycthread

он правда на с11 вроде как заточен.

Чем не устраивает pthreads (posix threads, он есть в mingw64) или многопоточность из стандартной библиотеки C++11?

pthreads для винды аж в нескольких вариантах есть

Вроде ничего выглядит. Но если брать pthreads, то мне придется это сперва в CMake завернуть (думаю, несложно), плюс надо тогда свою лапшу под Unix, потому как pthreads на разных системах надо компилить с разными параметрами, потом линковать по разному. Если посмотреть в код конфигурации той же GLib, то это можно увидеть. Хотелось бы не заниматься этим.

Это вроде ничего, но не увидел там rwlock. Или просмотрел?

Оно дружит с не-gcc компиляторами? Вообще, функционал подходит, даже сокеты есть. Правда выглядит жирновато.

не, это имплиментация стандарта С11, там нет rwlock. Но его можно самому на примитивах построить.

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

Я сам могу тогда уж и либу написать, хочется готового.

Посмотрел их код. Они почему-то не используют для rwlock и условной переменной на Винде нативное API, что в Висте появилось.

Поправь и закоммить...будь мужиком!

Пиши обертку. Над следующими вещами:

1) pthreads для всего, кроме винды 2) WinAPI для винды 3) Опционально, для UWP/etc

Дело в том, что pthreads, сколько я не смотрел реализаций, на винде реализованы через жопу. Например, несмотря на то, что в винде нативные Conditional Variables есть начиная с Vista, в том же Mingw64 он сделаны хер пойми как через очереди и эвенты.

кроссплатформенная либа

В идеале либа должна быть достаточно легковесной

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

есть перспективы запускать сабж на embedded

Просто чудо проектирования.

А по сабжу - я за pthreads.

Дело в том, что pthreads, сколько я не смотрел реализаций, на винде реализованы через жопу. Например, несмотря на то, что в винде нативные Conditional Variables есть начиная с Vista, в том же Mingw64 он сделаны хер пойми как через очереди и эвенты.

Вот! Именно это и пугает. Страшновато тащить эти велосипеды. Я надеялся, что кто-то уже сделал это.

1) pthreads для всего, кроме винды 2) WinAPI для винды 3) Опционально, для UWP/etc

В крайнем случае - да, придется.

Просто чудо проектирования.

Мопед не мой, но у заказчика тараканы знатные в голове. Мне бы лишь усилия минимизировать.

После реализации таких опусов Strategies for Implementing POSIX Condition Variables on Win32, Patterns for POSIX Condition Variables on Win32, наверное, никто не хочет трогать код, что хоть как-то работет.

Вот! Именно это и пугает. Страшновато тащить эти велосипеды. Я надеялся, что кто-то уже сделал это.

Так если без XP, какая же это кроссплатформенность?

В крайнем случае - да, придется.

это единственное здравое решение. подтвержу, что pthreads в маздае через жопу. причём сильно через жопу. но есть вероятность, что кто-то эту обёртку уже написал. хотя там не сказать, что много писать нужно.

Не-не, про «чудо» я имел ввиду библиотеку, которая могла бы одновременно удовлетворить всем требованиям.

Вторая из приведенных реализаций точно кривая.

Так если без XP, какая же это кроссплатформенность?

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

Значит pthreads точно отпадают. Понятно, что можно запилить самому, но объем возьни не радует: начиная от XP и заканчивая TLS всякими. Пока есть 2 кандидата, может кто еще знает что.

Не-не, про «чудо» я имел ввиду библиотеку, которая могла бы одновременно удовлетворить всем требованиям.

Про лекговесность имеется ввиду, что это не должно быть что-то типа Qt. Теоретически возможно.

Про Apache Apr уже, вроде, писали.

Про Apache Apr уже, вроде, писали.

В апаче условные переменные и rwlock тоже через задницу сделаны.

Если человек пытается что-то кроссплатформенное писать, то либо он сбредил, либо выбрал не ту работу.

Нафиг вообще эти мастдаи поддерживать? Кому в здравом уме может прийти в голову что-то разрабатывать (кроме игр) для этого говна?

Про лекговесность имеется ввиду, что это не должно быть что-то типа Qt. Теоретически возможно

а я хотел QThread советовать, ибо ну что значит «жирное», сколько там этот несчастный Qt Core кушает - чуток на диске, и немного оперативки, впрочем ладно, я бы весь софт писал на Qt от десктопа и сервера до embedded, до разумных пределов конечно

Как бы я сразу написал, что:

Нужна какая-то кроссплатформенная либа на С (именно C, C++ не годится)

Именно по этой причине Qt сразу же отпал.

В общем, дела не огонь. Первая (GLib) переходит в последний месяц с Autotools на какую-то самопальную систему сборки, которая написана на пистоне (OMG!). Тащить в проект пистон ради С-шной либы это изврат какой-то. Вторая (plibsys) собралась, тесты проходит. Но использовать ее все равно стремновато - про нее нигде ни слухом, ни духом. Боюсь потом нарваться на какой-нибудь ахтунг. Так что объявление о поиске в силе.

про нее нигде ни слухом, ни духом.

По крайней мере неделю назад автор оценил её статус настолько стабильным, что решился подать заявку в Debian: ITP: libplibsys0 — Highly portable C system library. Вот бы ещё хоть какую-нибудь историю успеха.

Вот бы ещё хоть какую-нибудь историю успеха.

Я про тоже. Потому что про GLib я знаю как оно и что там, но из-за своей толстоты не пролазиет. ITP в Дебиане не показатель совсем, там полторы тысячи таких ITP висят годами без пакетов.

Если решишь писать велик, то вот мой: https://github.com/tnodir/luasys/blob/master/src/thread/thread_sync.c

в mingw есть поддержка pthreads. Не знаю, есть ли реализация для VS, если есть безглючная - то это отличный вариант.

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

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

это УГ со сборкой уже немало распространилось. выпиливаю его везде при сборке пакетов, чтобы не ставить пистон. выпиливается на раз. на самом деле, пистон там не нужен чуть более, чем полностью. это просто сахар для тех, кто ниасилил написание makefile'ов. и он тупо их сам генерит. но зараза распространяется. это надо пресекать, чтобы с нормальными пакетами не тащились тонны питонячьего говна.

libuv

https://msdn.microsoft.com/ru-ru/library/y6h8hye8.aspx

libuv

Я правильно понимаю, что для сборки этого чуда под виндой нужен пистон?

В общем, решил остановиться пока на plibsys. По крайней мере, на нужных мне платформах оно работает (сделали простые тесты пока). Велик писать очень не хочется, тупо нет времени.

libuv в первом приближении вроде неплох был, но на Solaris не завелось, на hpux уже тестировать не стал.