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

я не думаю, что автоматом будет вызываться pthread_rwlock_unlock()

лучше тогда пусть будет UB с валидацией указателей, чтобы не вылететь за пределы буфера. Если потребителю полетит мусор это не так страшно, как если все зависнет.

если производитель перезапишет кадр под носом у потребителя, это в принципе не смертельно. Будут артефакты кратковременные

ты завязал часть драйвера на потребителя - тут ты очень не прав! низя так делать, если потребитель идиот. то ты получишь урезание ЗП и общественное поругание, оно тебе нужно?

копировать в юзерспейс собственноручно, из своего потока?

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

зачем копировать mmap и шаред мемори никто не отменял

шаред мемори уже есть. Туда пишет производитель. Нужно как-то забрать оттуда потребителю.

потребитель тебе стучит в пайп, ты ему говоришь читай 1ый буфер. он тебе ок. он тебя опять просит, ты ему читай сейчас 4-ый он самый новый.... и т.д

если он упадет тебе пофиг, когда он отдуплиться, он знает какой пайп открыть чтоб ты ему сказал откуда брать

пайп именованный!

сообщить потребителю адреса фреймов — это не проблема, тут сложностей не возникнет. Проблема в том, что бы пока потребитель себе в юзерспейс забирает кадр, его не перезаписал производитель (вместе с метаданными, призвав силу рандома)

а то произоводитель говорит: вот здесь лежит фрейм, такой-то адрес. Читай. Потребитель радостно читает, а производитель коварно его перезаписывает

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

у меня архитектура такая: есть кольцевой буфер (большой, общий для всех процессов). У этого кольцевого буфера есть состояние, в том числе начало и конец буфера. Есть API для потребителей, которое хранит состояние потребителя, то есть его текущий фрейм. Производитель покругу перезаписывает его, уничтожая старые данные. При этом, обновляются указатели на начало и конец. Но проблема в том, что производитель и потребитель могут встретиться. Т.е. производитель начнет писать туда, откуда читает потребитель. И тут уже UB

Проблема решается мьютексом, запрещающим одновременное чтение и запись. Но тут есть проблема отсутствия гарантии анлока. Мьютекс будет скрыт внутри API, но если потребитель упадет — то он не разлочится

Ор

побившийся видеопоток это лучше, чем дедлок

Мда