…причём сдохли ДО того как вызвали shm_unlink(). В этом случае мне нужно чтобы вновь запущенная куча процессов получила новую чистую память, а не старое состояние.
НЯП вызывать shm_unlink() сразу после mmap() нельзя: если после shm_unlink() другой процесс вызовет shm_open() с этим же именем, он получит другую область памяти.
Пишут, что в старом API (shmget(), …) это делается через shmctl(). Причём по дефолту там как раз нужное мне поведение, что есть правильно с т.з. защиты от race: SIGKILL может прилететь до shmctl(). …Хотя как-то мутно, в соседнем же каменте пишут наоборот, а по man shmctl вообще ни хрена не понятно.
То, что обращение в принципе возможно, я нагуглил. Интересует просад по скорости при чтении/записи 64-битных слов. У amd64 он исчезающе мал, так что вопрос «упаковывать данные или нет» вообще не стоИт.
#include <functional>
struct R {};
template<class... PP> void f(std::function<R(PP...)>) {}
struct P {};
int main() {
// No matching function for call to 'f'.
// Candidate template ignored: could not match 'std::function<R (PP...)>' against '(lambda at ...)'
f([&](P) { return R{}; });
// То же самое.
// UPD: Впрочем, не совсем: тут could not match 'std::function<R (P, PP...)>'. Бред какой-то.
f<P>([&](P) -> R { return R{}; });
}
Т.е. datagram, без подтверждения доставки, но с фрагментацией больших пакетов.
И чтобы сишная либа не выбрасывала хвост пакета если я ей буфер слишком маленький подсуну. Или например, чтобы я мог сначала спросить размер пакета, выделить буфер этого размера, и подсунуть этот буфер в recv().
Поскольку голосовалку если и подтвердят, то как обычно лет через 300, голосуем «палец вверх» / «палец вниз» своё отношение к SPA – КАК ЮЗЕРА (т.е. с т.з. usability), а не как программиста, SEO-шника, безопасника и т.п. – ПРИ ПРОЧИХ РАВНЫХ, в т.ч. при одинаковой нагрузке, прямоте рук программиста, размеру страниц (измеряемому количеством букв и картинок) и т.п.
В каментах накидаю аргументы, там голосуем «палец вверх» = «важный аргумент», «палец вниз» = «брехня это а не аргумент».
Если я уберу const с объявления msg внутри f(), и объявлю параметр data функции g() как const void*, а внутри напишу x.data = (char*)data, то всё сегфолтится. Почему?
Есть у меня проектик X, в котором собирается две либы: libX-buildtime.so и libX-runtime.so. Как понятно из названий, они линкуются в непересекающихся случаях, поэтому писать для них общий pkgconfig с общей строкой:
коряво и глупо. Да и зависимости у buildtime и runtime тоже разные, так что строка Requires.private тоже должна различаться.
Отсюда сабжевый вопрос: насколько это корректно/коряво с точки зрения дистро-мейнтейнеров, если при установке ОДНОГО пакета, в /lib/pkgconfig создаётся ДВА файла: X-buildtime.pc и X-runtime.pc?
К слову, в этом же проекте собираются ещё buildtime-утилиты, которые линкуют libX-buildtime.so, но это пофиг: в .pc-файле они не фигурируют.
Что печалит: вот допустим загрузил я картинку в память (в объект QImage) из ресурсов – и больше мне эти ресурсы не нужны. Но они продолжают сидеть в памяти, фактически задвоение данных картинки. А если там не картинка (которая во-первых маленькая, а во-вторых в теории может и не копировать эти данные, а тупо хранить ссылку на них с флагом owner=false), а чего пообъёмнее?
Понятно, что можно тупо хранить ресурсы в отдельном файле и грузить его вручную. Но не хочется файлы плодить. Вдруг есть какая-нибудь фича в плане сабжа? Смутно помню, что винда умеет красиво в ресурсы в PE-файлах, но мне бы под лялих.
$ cat makefile
b: a
cp a b
a:
# noop
$ rm -f a; touch b; make
# noop
cp a b
cp: cannot stat 'a': No such file or directory
make: *** [makefile:2: b] Error 1
По правилу a понятно: target file не существует – выполняем команды. Что команд нет – не наши проблемы.
А по правилу b не понятно ни черта. Оба правила не .PHONY, файл b существует, a не существует – и правило тем не менее выполняется.
Либо make после отработки правила a вообще не считывает mtime(a) повторно, а тупо берёт текущее время – но это крайне дурацкое кроилово для тулзы, которая на каждый чих в шел форкается. Собственно, я тут вообще глупость написал: что mtime, что текущее время – один syscall.
Либо же явно закодировано: если файл-зависимость не существует после выполнения правила-зависимости, то выполняем зависимое как будто его mtime < mtime зависимости. А нахрена?
// Вводная: я люблю SPA, так что без JS моё поделие работать один хрен не будет.
Я тут прикидываю, что кое-какую логику можно перенести из JS в WebAssembly с целью снижения трафика. Но без понятия насчёт сабжа: каким боком это вылезет? Расскажите кто на какие косяки нарывался (как разраб или юзер)?
all: bin lib
X := BIN
bin:
@echo 'Hello $(X)'
X := LIB
lib:
@echo 'Hello $(X)'
Вывод:
Hello LIB <--- а мечтался BIN
Hello LIB
ЧЯДНТ?
Проблему поймал когда попытался заюзать временные переменные внутри define ... endef, который потом подавался на вход $(eval $(call ...)). Т.е. исходный вопрос на самом деле ещё замороченнее: как юзать временные переменные внутри таких вот самодельных «функций»?
В доках GCC (ссылку не дам, уже потерял) прямым текстом сказано, что CMI (Compiled Module Interface) – формат не портабельный и может использоваться только для кеширования в процессе сборки. Он может меняться даже в зависимости от версии компилятора и целевой архитектуры, его смысл и scope примерно тот же что у precompiler headers. Что в общем естественно: компилятор сериализует туда свои внутренние структуры.
Следовательно, деплоить интерфейс модуля можно исключительно исходником. Т.е. если раньше было .h + .cpp, то теперь вместо .h у нас будет какой-нибудь .cppm – интерфейс модуля, который тоже надо деплоить вместе с либой, а в сорцах опять два исходника на модуль: .cppm + .cpp. Что поменялось? Расширение интерфейсного файла. Который теперь ещё и замусорен новыми кейвордами export и import.
Никаких намёков на попытки разработчиков компиляторов договориться о портабельном формате CMI и о расположении CMI-файлов внутри .a-архивов – не нагуглилось. Есть разве что вот такой пропозал в т.ч. про стандартный маппинг имён модулей на имена файлов, но читать его печально. Ну, может моим правнукам, работающим в поле пока светло, голубиная почта принесёт добрые вести.
Тьфу. Ни одну фичу не могут сразу нормально и ДО КОНЦА проработать.
Т.е. открыл я /run/my-socket, сишу слушаю, акцептю, пишу-читаю, всё non-blocking (select(2)).
Полагаю, внутри ядра такое accepted connection для локального unix domain socket – реализовано как обычный pipe?
Когда одна сторона пишет, мгновенно ли другой стороне прилетают данные (non-blocking просыпается из select(), клиентский blocking read() возвращает управление), или там может буферизация какая или ещё какая дичь?
Можно конечно тупо сконвертнуть весь буфер в wstring и потом работать с ним как белый человек. Но мой внутренний байтодрочер ужасается от sizeof(wchar_t) и подозревает, что посимвольно читать буфер будет быстрее.
Чтобы, значит, и рунглишом ни себя ни других не мучить, и чтобы, значит, своим распрекрасным и сверхнужным кодом поддержать отечественных программистов в их трудной борьбе конкуренции с буржуями.
Отговорите.
Кстати 1: а разрабы Astra Linux (или что там у нас для госорганов сертифицировано) в своём коде по-английски каментят?
Кстати 2, чтобы 2 раза не вставать: а внутри РФ вообще имеют смысл такие слова как GPL? В т.ч. с точки зрения суда.
Обновил wine 6.22 на 7.7. (Долго тянул т.к. глючная дрянь этот ваш wine.) Вид всех контролов в прогах (дочерних окон в MDI, кнопок, таблиц и т.п.) стал отвратительным: бьющим по глазам ярко белым и плоским. Весь гуй превратился в равномерно-ярко-белое пятно. В т.ч. в самом winecfg: тут не вполне белый, но светло-серый и тоже плоский (e.g. кнопки того же цвета что фон окна). Как вернуть взад?