(Q)SharedMemory при крахе программы

Просто странная ситуация получается - ну упала программа, упало и то что создало и использовало - а ресурс кто освобождать будет?

<br/><br/> Никто не будет, это тебе не виндовс, тут всё брутально. Шареную память можешь ручками прибить командой ipcrm.

Не знаю, как в этой вашей Qt, а в Unix/Linux можно настроить сегмент разделяемой памяти так, чтобы он удалялся после завершения использующих его процессов.

... но знание о том, как это делается, я унесу с собой в могилу.

... но знание о том, как это делается, я унесу с собой в могилу.

Это да, но даже после этого оно останется в man 2 shmctl, пункт IPC_RMID.

тайну эту нам рассказать желаешь ты

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

А мерзким кутешникам должно быть достаточно официальной документации:

Unix: QSharedMemory «owns» the shared memory segment. When the last thread or process that has an instance of QSharedMemory attached to a particular shared memory segment detaches from the segment by destroying its instance of QSharedMemory, the Unix kernel release the shared memory segment. But if that last thread or process crashes without running the QSharedMemory destructor, the shared memory segment survives the crash.

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

Ты так строго об этом спросил, что я аж полез в man shmdt. Ну да, разделяемая память детачится в _exit.

что делать - программа крэшнулась - а дальше что? повторный запуск - просто attach?

Ты так строго об этом спросил, что я аж полез в man shmdt. Ну да, разделяемая память детачится в _exit.

Хм, проверил - так и есть, после крэша высвободилась. Но при этом заметил, что после вызова «shmctl(shmid, IPC_RMID, 0)» ключ сегмента в выводе ipcs обнуляется. Т.е. получается, что IPC_RMID можно устанавливать только когда все заинтересованные стороны к этой памяти уже подключились. А если прога грохнется до этого - эффект всё тот же. Каждый раз поражаюсь тому, насколько разработчики NT-шного ядра были умнее.

пока что я решил это перехватом сигналов SIGSEGV SIGKILL и SIGQUIT - вот там я делаю detach - пока работает

но такая реализация меня огорчает - ведь должна же ОС понимать что от ресурса отвалились все потребители, примерно так же как выгружается *.so когда все потребители кильнулись...

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

Кстати, под вайном такой хрени не должно быть. Не проще сразу писать под вайн? И проблем с кроссплатформенностью не будет, и нет этого системвэшного говна мамонта в АПИ. В ВинАПИ же всё просто и логично, и никто не мешает рассматривать его как библиотеку системных функций линупса.

нет, проще писать скрипт-обёртку для бинарников, предочистка, посточистка и всё такое :) что не делает ОС и я делаю вручную - может делать скрипт

Не знаю чем это проще, просто привносится лишняя сущность.. Хотя нормально в юниксах примерно так и поступают: делают демона, который порождает всех этих владельцев разделяемой памяти, а если те сдохли - то перестартует их, ну и всякой такой хозяйственной работой занимается. Ведь разделяемая память между неродственными процессами обычно нужна в случаях, когда есть некий «сервер» который создаёт сегмент, к которому все остальные процессы подключаются как клиенты. Уродство системы рождает уродские воркэраунды.

я не сторонник эмоциональных оценок, раз сделано - была причина, хотя мне она не ясна

просто не хотелось лишнего копирования между процессами, но возможно это не так накладно будет для меня и я перепишу без shared memory

либо сделаю внешнее создание/удаление областей этой памяти (в запускающем скрипте) - вполне себе нормальное решение будет

я не сторонник эмоциональных оценок, раз сделано - была причина, хотя мне она не ясна

Да с причиной-то всё понятно. Технологии развиваются со временем, появляются принципиально новые подходы, решения, видение роли ОС базирующиеся на уже пройденных человечеством граблях. Так плюсы превратились в Джаву из которой были максимально убраны эти самые пресловутые грабли, на которые постоянно наступают программисты, так разработчики NT решили наконец отказаться от того нелогичного нагромождения костылей в которое со временем превратились юнипсы и создать простую и логичную систему вызовов, лишенную этой дурацкой избыточности.. Ты знаешь, что в линупсе ты можешь реализовать разделяемую память не только через shm, но и через mmap? А поименование разделяемых объектов в ipc принято делать через функцию ftok, которая из символического имени тебе сделает ключ объекта, что саом по себе костыль, но что ещё смешнее, это имя должно соответствовать физически существующему файлу. Кажется глупым? А есть люди, которые добровольно пользуются такими системами. Я вот тоже не могу понять их мотивацию.

меня не интересуют эти сопли, мне либо по теме пиши, либо свободен

так же, меня не интересуют ОС семейства NT

единственная проблема лишь то что ресурс не освобождается автоматически, не велика беда - я думал QSharedMemory работает через mmap

The main difference between System V shared memory (shmem) and memory mapped I/O (mmap) is that SystemV shared memory is persistent: unless explicitly removed by a process, it is kept in memory and remains available until the system is shut down. mmap'd memory is not persistent between application executions (unless it is backed by a file).

ну не беда, перепишу при помощи mmap - опять же не беда

меня не интересуют эти сопли, мне либо по теме пиши, либо свободен

Разве это ты размазывая сопли кураком тут вопил «я не понима-а-а-аю, мамочка», малыш?

так же, меня не интересуют ОС семейства NT

Ну и что с того? Покажи мне того, кому тут было бы интересно, что именно тебя лично интересует? Это форумо об ОС, а не о тебе любимом.

ну не беда, перепишу при помощи mmap - опять же не беда

Ага. Небеда на небеде небедой погоняет.

давно пора закрыть ЛОР для анонимов, а то ишь набежало вендотроллей, вообще охренели - в моем же топике серут, типа что ты делаешь в своем топике )))

но за mmap спасибо :)

В этом я с тобой согласен. Свободное сообщество нужно освободить от анонимов, да и от некоторых регистрантов тоже. Чтобы не было, понимаешь, такой фигни, что то линупс неправильно напишут, или там усомнятся в совершенности этой ОС, или в юзер-агенте напишут что-нибудь непристойное.. Я вижу, что определённые шаги в этом направлении принимаются, но пока что усилия модераторов недостаточны. Надо как-то жёстче с нами, с анонимусами. Иначе капец же этому нашему линупсу.

ну да, сидят тут не знают что есть божественная идеальная венда, разве умный человек будет использоваться что-то кроме Microsoft (R) Windows (R) с новой super mega extending tehnology (tm)

Т.е. получается, что IPC_RMID можно устанавливать только когда все заинтересованные стороны к этой памяти уже подключились.

Да. Но я не вижу в этом проблемы, особенно если это тот usecase, о котором я думаю. Впрочем, если это он, там вообще не нужно разделяемой памяти %)

Каждый раз поражаюсь тому, насколько разработчики NT-шного ядра были умнее.

Indian Hill IPC делали люди, которые относились к Unix... ну примерно так же, как ты.

Indian Hill IPC делали люди, которые относились к Unix... ну примерно так же, как ты.

Тебе показалось что я настолько ненавижу юниксы что-ли? Просто АПИ - это та часть, которую нужно менять. Она себя изжила. Хотя, пока Поттеринг не доберётся до АПИ, ничто никуда не сдвинется.

Тебе показалось что я настолько ненавижу юниксы что-ли?

Нет. Мне показалось, что ты относишься к Unix как к куче устаревшего хлама. Люди, сделавшие Indian Hill IPC, относились к Unix так же - в результате мы имеем хрень.

Просто АПИ - это та часть, которую нужно менять.

Потому что нужно.

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

А, не понял сразу что ты подразумевал под «отношением» :)

Люди, сделавшие Indian Hill IPC, относились к Unix так же - в результате мы имеем хрень.

Люди, сделавшие винапи также относились к Unix, но это не помешало создать им цельное и логичное АПИ (ну и докучи и новое ядро приделать к нему, но в принципе какая разница что там за ядро). Видимо, тут проблема не в отношении к Unix :)

Люди, сделавшие винапи также относились к Unix

А к ядру VMS, которое они переписывали, они относились очень хорошо. Так что всем пофиг, как они относились к Unix или, например, китайской кухне.

семёрочку обновил уже?

Упаси Бог! Еще там его нехватало. Тогда линупсу точно кердык(.

Упаси Бог! Еще там его нехватало. Тогда линупсу точно кердык(

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

не в состоянии посмотреть на вещи здраво

многие думают, в том числе и я, что как раз наоборот.

и создать нечто принципиально новое

Миша, всё перепишем! У тебя скучное лицо! Тебе никто денег не даст! ©

пока что я решил это перехватом сигналов ... SIGKILL ...

ШИТО?

man Genode OS - достаточно принципиально новое?

что тебя удивляет? это всё перехватывается и на последнем издыхании релизит

Хм, странно. Я думал ОСь должна считать рефы зависимостей от шареной памяти, и при принудительном отмирании анрефить и далее как обычно if(ref_cnt < 1) unmap(...).

Именно! И любой нормальный человек считает так же. Потому что это - естественное поведение, которого мы ожидаем от ОС! Но к сожалению, чуть ли не каждая из системных функций UNIX'a ведёт себя не совсем так, как ожидает человек, предлагая пользователям широкий выбор фичей, понять которые невозможно в свете отсутствия какого-либо оправдания такому поведению. Что в свою очередь порождает относительно большое (если сравнивать с теми же самыми вендами) количество ошибок в коде, который в компаниях оборачивается дополнительными затратами на тестирование и потерями прибыли при отказах в боевых серверах.

это чушь, я давно пишу под Linux и пользуюсь Qt и прочими библиотеками - никаких проблем и увеличенных сроков тестирования не возникает

а это несчастное shared memory лишь исключение

это чушь, я давно пишу под Linux

Категоричность суждений выдаёт нам что в твоём возрасте говорить о «давно» ещё не приходится, а то, что

и пользуюсь Qt

какбэ намекает нам что промышленных серверов ты ещё не нюхал.

а это несчастное shared memory лишь исключение

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

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

(C)man 7 signal

ты прав, но я добавил хэндлеры и вроде даже стало что-то работать - иллюзия вышла :)

но это всё не то...

я покопался в исходниках Qt - во-первых я удостоверился что Qt использует новомодный mmap механизм для shared memory а не устаревший (т.е. я был прав что так думаю), но! использует совместно устаревшие семафоры

т.к. QSharedMemory юзает QSystemSemaphore (а тот в свою очередь устаревшие семафоры и т.к. это в недрах Qt - нет возможности заставить открывать с другими флагами, которые бы решили проблему) теперь я запускаю свои программы через скрипт, а тот в свою очередь чистит неиспользуемые семафоры

причем крах клиентов не блокирует этот семафор (естественно) а при крахе сервера - скрипт чистит семафоры

вот скрипт:

#!/bin/bash

export LANG=C

ME=`whoami`

IPCS_S=`ipcs -s | egrep "0x[0-9a-f]+ [0-9]+" | grep $ME | cut -f2 -d" "`
IPCS_M=`ipcs -m | egrep "0x[0-9a-f]+ [0-9]+" | grep $ME | cut -f2 -d" "`
IPCS_Q=`ipcs -q | egrep "0x[0-9a-f]+ [0-9]+" | grep $ME | cut -f2 -d" "`


for id in $IPCS_M; do
  ipcrm -m $id;
done

for id in $IPCS_S; do
  ipcrm -s $id;
done

for id in $IPCS_Q; do
  ipcrm -q $id;
done

echo "shared memory cleared"