Boost interprocess что это за папка
папка boost_interprocess
Здравствуйте, заметил у себя в папке ProgrammData папку boost_interprocess. Датируется 04.06.15. Проверил, в тот же день обновлялся драйвер nVidia и игра Bastion. Эта папка как-то связана с этим? Или это что-то другое?
В общем тут такое. У меня стоит Geforce Experience. Сейчас запустил его, он начал обновляться. Чекнул, папка
boost_interprocess
тоже обновилась
Получается это хвост программы GeForce Experience>??
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
Ну да. Просто через трей запустил программу, она автоматически стала обновляться
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
Обновилась, потом автоматически запустилась
Нетфильтр контролирует трафик который вы используете, данная папка от него.В данном случае он проверял на наличие вирусов трафик, который использовал GeForce.
Нетфильтр контролирует трафик который вы используете, данная папка от него.В данном случае он проверял на наличие вирусов трафик, который использовал GeForce.
Так а что такое нетфильтр? Я вроде бы ничего такого не устанавливал.
dr web у вас стоит.
dr web у вас стоит.
нет. стандартный защитник
dr web у вас стоит.
так что же? насчет папки стоит беспокоиться?
А в папке что-нибудь есть?
А в папке что-нибудь есть?
папка 20150621192021.492045. это папка пуста
А скрытых файлов нет?
А скрытых файлов нет?
Мне кажется беспокоится не стоит.Подождём мнения экспертов.
Мне кажется беспокоится не стоит.Подождём мнения экспертов.
а из-за чего папка возникла? можете сказать?
у меня тож такая есть, происхождение не известно
boost interprocess что за папка
Я прочитал немного о boost::interprocess::file_lock и он, кажется, делает в значительной степени то, что мне нужно (поддержка разделяемой и эксклюзивной блокировки и разблокировка в случае сбоя или выхода из процесса).
Хотя в чем я не уверен, так это в чем делать в файл? Могу ли я использовать, например, файл длиной 0 байт? Есть ли boost::interprocess написать что-нибудь в это? Или о его присутствии заботится вся система?
Я использую boost::interprocess теперь в течение некоторого времени для надежного отображения в памяти файла и записи в него, теперь мне нужно выполнить многопроцессорность и убедиться, что чтение и запись в этот файл защищены; file_lock действительно кажется, что путь, мне просто интересно, если мне теперь нужно добавить еще один файл для использования в качестве мьютекса.
Решение
Boost ничего не делает с файлом, он полагается на операционную систему, чтобы выполнить эту работу. Поддержка отображаемых в память файлов является общей возможностью операционной системы виртуальной памяти с постраничной загрузкой. Как Windows, Linux, OSX. Память, как правило, поддерживается файлом подкачки, а резервное копирование этого файла — это лишь небольшой шаг. Boost просто предоставляет независимый от платформы адаптер, и ничего более.
Имейте в виду, что это очень Механизм взаимодействия низкого уровня и не имеет никаких удобств. К тому времени, когда вы добавляете всю необходимую синхронизацию, вы уже на полпути к тому, что ОС уже делает с именованным каналом или сокетом локальной петли. Если вы обнаружите, что вам необходимо скопировать данные в отображенное представление, что не редкость, поскольку его нелегко изменить, то вы потеряете все преимущества.
Пытаюсь построить класс в памяти, и потом в другом процессе его прочитать. Почему-то выдаёт другой адрес и вылетает Segmentation fault
1 ответ 1
30 просмотра
1 ответ
1 Репутация автора
Я искал StackOverflow и обнаружил два потока, относящихся к «boost interprocess», но оба они в основном касаются только ОС Windows и также не обсуждают проблему, с которой я столкнулся. Тот же поиск в Google — та же проблема — ОС Windows, а также большинство дискуссий имеют возраст.
Моя проблема: На моем iMac (Mojave OS) в папке «Мои документы» неожиданно появилась папка с именем «boost_interprocess». Внутри папки находится документ с именем «pdfEngine-10.0.472-0a71a373-fe27-499f-be0c-2d67402dc128_shm». Каждый раз, когда это появлялось, я удалял это и очищал мусор. Это случайно появляется на следующий день или несколько дней спустя. Я запустил Malwarebytes, и он не распознает его как угрозу.
Мой вопрос: кто-нибудь знает, что это такое и как навсегда удалить его?
Ответы (1)
168 Репутация автора
Файлы, которые вы видите в папке, называются объектами общей памяти.
В вашем случае, похоже, что некоторые данные механизма PDF передаются таким образом, и нет причин для тревоги.
папка boost_interprocess
Здравствуйте, заметил у себя в папке ProgrammData папку boost_interprocess. Датируется 04.06.15. Проверил, в тот же день обновлялся драйвер nVidia и игра Bastion. Эта папка как-то связана с этим? Или это что-то другое?
В общем тут такое. У меня стоит Geforce Experience. Сейчас запустил его, он начал обновляться. Чекнул, папка
boost_interprocess
тоже обновилась
Получается это хвост программы GeForce Experience>??
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
Ну да. Просто через трей запустил программу, она автоматически стала обновляться
GeForce ЧЕРЕЗ ИНТЕРНЕТ ОБНОВЛЯЛИ.
Обновилась, потом автоматически запустилась
Нетфильтр контролирует трафик который вы используете, данная папка от него.В данном случае он проверял на наличие вирусов трафик, который использовал GeForce.
Нетфильтр контролирует трафик который вы используете, данная папка от него.В данном случае он проверял на наличие вирусов трафик, который использовал GeForce.
Так а что такое нетфильтр? Я вроде бы ничего такого не устанавливал.
dr web у вас стоит.
dr web у вас стоит.
нет. стандартный защитник
dr web у вас стоит.
так что же? насчет папки стоит беспокоиться?
А в папке что-нибудь есть?
А в папке что-нибудь есть?
папка 20150621192021.492045. это папка пуста
А скрытых файлов нет?
А скрытых файлов нет?
Мне кажется беспокоится не стоит.Подождём мнения экспертов.
Мне кажется беспокоится не стоит.Подождём мнения экспертов.
а из-за чего папка возникла? можете сказать?
у меня тож такая есть, происхождение не известно
Ускоряем передачу данных в localhost
Один из самых быстрых способ межпроцессного взаимодействия реализуется при помощи разделяемой памяти (Shared Memory). Но мне казалось не логичным, что в найденных мною алгоритмах, память всё равно нужно копировать, а после перезапуска клиента (причём он допускался только один) нужно перезапускать и сервер. Взяв волю в кулак, я решил разработать полноценный клиент-сервер с использованием разделимой памяти.
И так, вначале нужно определить функциональные требования к разрабатываемому клиент-серверу. Первое и основное требование: данные не должны копироваться. Во вторых, «мультиклиентность» — к серверу могут подключаться несколько клиентов. В третьих, клиенты могут переподключаться. И в четвёртых, по возможности ПО должно быть кроссплатформенно. Из налагаемых требований, можно выделить составные части архитектуры:
Реализация клиента и сервера
Реализация передачи данных между клиентами и серверов достаточно тривиальна. Она похоже на реализацию модели поставщик-потребитель (producer-customer) с использованием семафоров, где в качестве «передаваемого» сообщения используется смещение (адрес) передаваемого буфера, а объекты синхронизации заменены на их межпроцессные аналоги. Каждому клиента и серверу соответствует своя очередь смещений, которая играет роль приёмного буфера и семафор, который отвечает за уведомление об изменении очереди. Соответственно, когда буфер отправляется другому процессу, то смещение буфера кладётся в очередь, а семафор освобождается(post). Далее другой процесс считывает данные и захватывает семафор (wait). По умолчанию процесс не ждёт получения данных другим процессом(nonblock). Пример реализации можно взять отсюда. На практике, помимо передачи самого буфера зачастую необходимо еще передать идентифицирующую информацию. Обычно это целочисленное число. Поэтому в метод Send добавлена возможность передачи числа.
Как клиенты подключаются к серверу?
Алгоритм достаточно прост, данные о сервере лежат строго по определённому смещению в разделяемой памяти. Когда клиент «открывает» разделяемую память он считывает структуру по заданному адресу, если её нет, то сервер отсутствует, если есть, то он выделяет память для структуры данных клиента, заполняет её и возбуждает событие на сервере с указанием смещения на структуру. Далее сервер добавляет нового клиента в связанный список клиентов и возбуждает в клиенте событие «подключён». Отключения осуществляется аналогичным образом.
Оценка состояния соединения
Проверка состояния соединения между клиентом и сервером построена аналогично TCP. С интервалом времени отправляется пакет жизни. Если он не доставлен – значит, клиент «рухнул». Также чтобы избежать возможных взаимных блокировок(dead lock) из-за «рухнувшего» клиента, который не освободил объект синхронизации, память для пакета жизни выделяется из собственного резерва сервера.
Реализация менеджера памяти
Как оказалась, самая сложная задача в реализации подобно IPC — это реализация менеджера памяти. Он ведь должен не просто реализовать методы malloc и free по одному из известных алгоритмов, но и не допустить утечки при «падении» клиента, предоставить возможность «резервировать» память, выделять блок памяти по конкретному смещению, не допускать фрагментирования, быть потокобезопасным, а в случаи отсутствия свободных блоков требуемого размера, ожидать его появления.
Базовый алгоритм
За основу реализации менеджера памяти был взят Free List алгоритм. Согласно этому алгоритму, все не выделенные блоки памяти объединяются в односторонний связанный список. Соответственно, при выделении блока памяти (malloc), ищется первый свободный блок, размер которого не меньше требуемого, и удаляется из связанного списка. Если размер запрашиваемого блока меньше чем размер свободного, то свободный блок разбивается на два, первый равен запрашиваемому размеру, а второй «лишнему». Первый блок – это выделенный блок памяти, а второй добавляется в список свободных блоков. При освобождении блока памяти(free), освобождаемый блок добавляется в список свободных. Далее соседние свободные блоки памяти объединяются в один. В сети есть множества реализация менеджера памяти с алгоритмом Free List. Я использовал алгоритм heap_5 из FreeRTOS.
Алгоритмические особенности
С точки зрения разработки менеджера памяти, отличительной особенностью работы с разделяемой памятью является отсутствие «помощи» со стороны ОС. Поэтому помимо списка свободных блоков памяти, менеджер также обязан сохранять информацию о владельце блока памяти. Сделать это можно несколькими способами: хранить в каждом выделенном блоке памяти PID процесса, создать таблицу «смещение выделенного блока памяти – PID», создать массив выделенных блоков памяти для каждого PID отдельно. Поскольку количество процессов обычно мало (не больше 10), то было принято гибридное решение, в каждом выделенном блоке памяти храниться индекс (2 байта) массива смещений выделенных блоков памяти, каждому PID соответствует свой массив, который расположен в конце «блока процесса» (в этом блоке храниться информация о процессе) и является динамическим.
Массив организован хитро, если блок памяти выделен процессом, то в ячейке храниться смещение выделенного блока памяти, если блок памяти не выделен, то в ячейке содержится индекс следующей «не выделенной» ячейки (фактически организован односвязный список «свободных» ячеек массива, как в алгоритме Free List). Такой алгоритм работы массива, позволяет производить удаление и добавление адреса за константное время. Причём при выделение нового блока искать таблицу соответствующую текущему PID необязательно, её смещение всегда известно заранее. А если сохранять смещение «блока процесса» в выделенном блоке памяти, то при освобождении блока искать таблицу также не надо. Из-за принятого допущения о малости количества процессов, «блоки процессов» объединены в односторонний связанный список. Таким образом, при выделении нового блока памяти (malloc) сложность добавление информации о владельце равна О(1), а при освобождении(free) блока памяти О(n), где n – количество процессов использующих разделяемую память. Почему нельзя использовать дерево или хэш-таблицы для быстрого поиска смещения «блока процесса»? Массив выделенных блоков является динамическим, следовательно, смещение у «блока процессов» может измениться.
Как писалось выше, для работы «клиент-сервера» необходимо добавить возможность «резервирования» блоков памяти. Это реализуется достаточно просто, резервный блок памяти «выделяется»для процесса. Соответственно, когда необходимо выделить блок памяти из резерва, то резервный блок процесса освобождается, и далее операции аналогичны обычному выделению. Далее, выделения блока памяти по заданному адресу реализуется тоже просто, т.к. информация о выделанных блоках храниться в «блоке процесса».
При таком большом количестве постоянно хранящейся служебной информации может возникнуть фрагментация памяти из-за разной времени «жизни» блоков, поэтому в менеджере памяти вся служебная информация(большое время жизни) выделяется с конца области, а выделение «пользовательских» блоков(малое время жизни) сначала. Таким образов, служебная информация будет фрагментировать память только при отсутствии свободных блоков.
Структура памяти представлена на рисунке ниже.
А что произойдет, если один из процессов использующих разделяемую память рухнет?
К сожалению, я не нашёл способа получить событие от ОС «процесс завершился». Но есть возможность проверить существует процесс или нет. Соответственно, когда в менеджере памяти возникает ошибка, например, закончилась память, то менеджер памяти проверяет состояние процессов. Если процесса не существует, то на основании данных хранящихся в «блоке процесса» утекшая память возвращается в оборот. К сожалению, из-за отсутствия события «процесс завершился», может возникнуть ситуация когда процесс рухнул в момент владения межпроцессным мъютексом, что естественно приведёт к блокировке менеджера памяти и невозможности запуска «очистки». Чтобы этого избежать, в заголовок добавлена информация о PID владельца мъютекса. Поэтому, при необходимости, пользователь можно вызывать проверку принудительно, скажем каждых 2 секунды. (метод watch dog)
Из-за использования «copy-on-write», может произойти ситуация, когда буфером владеют одновременно несколько процессов, причём по закону подлости, один из них рухнул. В этом случае могут возникнуть две проблемы. Первая, если рухнувший процесс являлся владельцем буфера, то он будет удалён, что приведёт к SIGNSEV у других процессов. Вторая, из-за того что рухнувший процесс не уменьшил счётчик в буфере, то он никогда не будет удалён, т.е. возникнет утечка. Простого и производительного решения этой проблемы я не нашёл, но, к счастью, такая ситуация редкость, поэтому я принял волевое решение, если кроме упавшего процесса есть ещё один владелец, то чёрт с ним, пусть память утекает, буфер перемещается к процессу запустившему очистку.
Обычно менеджер памяти в случае отсутствия свободного блока памяти возвращает NULL или выбрасывает исключение. Но нас ведь «интересует» не выделения блока памяти, а его передача, т.е. отсутствие свободного блока, говорит не об ошибке, а о необходимости подождать пока другой процесс освободит блок. Ожидание в цикле, обычно дурно пахнет. Поэтому менеджер имеет два режима выделения: классический, если нет свободного блока, возвращает NULL и ожидающий, если нет свободного блока, то процесс блокируется.
Реализация оставшихся компонентов
Основу реализации оставшихся компонентов составляет boost, поэтому далее я остановлюсь только на их особенностях. Особенностью компонента, инкапсулирующего работу с разделяемой памятью (далее CSharedMemory) наличие заголовка с межпроцессным мютексом для синхронизации методов работы с разделяемой памятью. Как показала практика, без него не обойтись. Поскольку обычно размер буфера данных не изменяется или изменяется только с начала (например, вставка заголовка в буфера данных для передачи по сети.) алгоритм резервирование памяти в CBuffer отличен от коэффициентного алгоритма резервирования памяти в std::vector. Во-первых, в реализации CBuffer добавлена возможность задавать резерв сначала, по умолчанию он равен 0. Во-вторых, алгоритм резервирования памяти следующий: если размер выделяемого блока меньше 128 байт, то резервируется 256 байт, если размер буфера данных меньше 65536, то резервируется размер буфера плюс 256 байт, в противном случае резервируется размер буфера плюс 512 байт.
Несколько слов по поводу использования sem_init в Linux
Основные источники дают не совсем корректную версию программного кода использования sem_init между процессами. В Linux необходимо выравнивать память для структуры sem_t, например вот так:
Поэтому, если у вас sem_post(sem_wait) возвращает EINVAL, попробуйте выровнять память для структуры sem_t. Пример работы с sem_init.
Итого
В результате получился клиент-сервер, скорость передачи которого не зависит от объёма данных, она зависит только от размера передаваемого буфера. Цена этому – некоторые ограничения. В Linux наиболее существенное из них — это «утечка» памяти после «завершения» процесса. Её можно удалить вручную или перезапустить ОС. При использовании в windows проблема иная, там «утекает» разделяемая память на жёстком диске, если она не была удалена вызовом метода класса сервера. Эта проблема не устраняется перезапуском ОС, только ручным удалением файлов в папке boost_interprocess. Поскольку мне иногда приходиться работать со старыми компиляторами, в репозитории лежит boost версии 1.47, хотя с последними версиями, библиотека работает шустрее.
Результаты тестирования представлены на графике ниже (Linux и QNX тестировались в виртуальной машиной VMBox)
Где взять исходники?
Исходный код стабильной версии лежит здесь. Там же есть и бинарники (+ VC redistributable) для быстрого запуска теста. Для любителей QNX в исходниках есть toolchain для CMake. Напоминаю, если CMake не собирает исходники, почистите переменные окружения, оставляя только каталоги целевого компилятора.
И напоследок ссылка на реализацию LookFree IPC с использованием разделяемой памяти.
Boost interprocess что это за папка
» refers to either “C:\Documents and Settings\All Users\Application Data” or “C:\ProgramData”, depending on the version of Windows operating system. The folder name “ . ” is created from the system date and time value.
Thanks for the info but I don’t think we are dealing with something else. We have an update version of virus scanner and definitions and the properties of the malware doesn’t match correctly. Here is one set of files we have:
Probably some variant of it then. More info here.
Old thread so this may no longer be relevant, but I also found the boost_interprocess folder in C:\ProgramData. I have discovered that the boost_interprocess folder, and its contents, are created by the Cloudfogger app on my system.
Cloudfogger is (was) an app to automatically encrypt the contents of folders synced with cloud storage services. Unfortunately, there has been no activity from them since December 2012, and they are not responding to contact.
I’m not saying that their software is purposefully malicious because I have no evidence, other than the creation of that folder, that anything untoward is happening. However, bearing in mind the lack of development and response, I have uninstalled Cloudfogger which has allowed me to delete the boost_interprocess folder, and, without Cloudfogger running, it doesn’t come back.