Qt shared memory - поиск незанятого ключа

Сигналы SIGSEGV и SIGFPE посылаются отдельному потоку, а не процессу. Т.е. можно запустить ненадёжный код в отдельном потоке и при поимке сигнала сделать бочку (см. второй пост там).

Говорили мне как-то, что число ключей в Shared Memory во FreeBSD 98-го года было ограничено то ли восемью, то ли шестнадцатью. Так что может лучше всё-таки пайпы, если отдельным процессом.

Кстати, сишный API к clang крешебезопасен, и он как раз делает бочку в упавшем потоке.

Сигналы SIGSEGV и SIGFPE посылаются отдельному потоку, а не процессу. Т.е. можно запустить ненадёжный код в отдельном потоке и при поимке сигнала сделать бочку (см. второй пост там).

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

да, именно так, запоров некую область памяти лишь только бессовестно выйдя за рамки будет sigsegv

а оно тебе надо?? расшаренная память - не самый лучший способ, лучше попользуй что-нибудь более безопасное, например общение по сети, а чтобы было более прозрачным - RPC тебе в помощь (или CORBA, тут уж на любителя)

вынести обработку некоего не совсем надежного в плане сбоев кода в отдельный процесс.

я решил использовать QSharedMemory.

Так себе решение. Если твой «не совсем надежный код» сегфолтнется или зациклится, что станет с разделяемой памятью?

способы быстро обменяться областью памяти несколько мегабайт 5 раз в секунду + 10 в парраллель?

Скажем, 25-50 Мбайт/с? Я думаю, любой IPC, включая TCP-сокеты.

Есть, кстати, один трюк: готовишь данные, потом делаешь fork для выполнения «ненадежного кода», а он отдает результат через пайп (или сегфолтится, но это легко обнаруживается).

если приложение многопоточное, то этот трюк может оказаться слишком геморройным

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