Я разработал библиотеку на C ++, которая позволяет использовать многопоточность. Я хочу поддержать опцию для вызывающего абонента, чтобы указать ограничение на память, выделенную данным потоком. (Мы можем игнорировать случай, когда один поток выделяет память, а другие используют ее.)
Возможно, это усложняется тем, что моя библиотека использует различные компоненты с открытым исходным кодом (boost, ICU и др. c), некоторые из которых которые статически связаны, а другие динамически.
Один вариант, который я изучал, - это переопределение функций выделения (new / delete / et c) для ведения учета по идентификатору потока. Естественные проблемы возникают вокруг бухгалтерии: производительность и т. Д. Но еще больший вопрос / проблема заключается в том, будет ли этот подход работать с компонентами с открытым исходным кодом без изменения кода в них?
Я не могу найти уже существующие решения для этого, хотя мне кажется, что это не очень необычно.
Есть предложения по этому подходу или другому подходу?
РЕДАКТИРОВАТЬ: Больше информации: библиотека может выделять значительно больший диапазон памяти для каждого вызывающего потока в зависимости от предоставленного ввода (ie. КБ к ГБ). Таким образом, целью этого запроса является (более любезно и детерминистически) поддержка работы в средах с ограниченным объемом ОЗУ. Это не для жесткой среды реального времени со строгими ограничениями памяти - она поддерживает несколько параллельных потоков, каждый из которых имеет «безопасный» предел выделения, чтобы избежать использования файла подкачки / подкачки.
Основы c пример использования: система с 32 ГБ ОЗУ, 20 ГБ свободно, приложение, использующее мою библиотеку, может настроить себя на использование максимум 10 потоков и настроить библиотеку на использование не более 1 ГБ на поток.
После нажатия на верхний предел вызов текущего потока в библиотеку прекратит дальнейшую работу и вернет подходящую ошибку. (Код уже полностью RAII, так что чистое разматывание легко.)
Кстати, я уже нашел какой-то интересный контент в Интернете, к сожалению, никто не дает много надежды на «простое и эффективное» решение. Но этот особенно проницателен.