Господа подскажите плз.
Есть два процесса, открывших один и тот же файл - первый на чтение, а второй на запись так, что в это же время дописывает данные в конец файла, увеличивая его размер. Необходимо в третьем процессе узнать, в какой точке файла находится читающий процесс для того,
чтобы не дать ему наткнуться на конец файла в случае опережения чтения перед записью. Какможно узнать его оффсет?Спасибо!
>Господа подскажите плз.
>Есть два процесса, открывших один и тот же файл - первый на
>чтение, а второй на запись так, что в это же время
>дописывает данные в конец файла, увеличивая его размер. Необходимо в третьем
>процессе узнать, в какой точке файла находится читающий процесс для того,
>
>чтобы не дать ему наткнуться на конец файла в случае опережения чтения
>перед записью. Какможно узнать его оффсет?
>
>Спасибо!узнать просто, пусть он который читает, этот офсет выдает, ну к пимеру в пайп. можно во временный файл. вообщем как хочешь.
Я правда так не делал, но вот вопрос, а что такого страшного произойдет если этот процесс столкнется с концом файла? как в фильме про Ван дама, нельзя было сталкиваться со своим двойником ;-))). Вообщем конец файла данных, это еще не конец программы, можно после этого поспать и еще раз попробовать прочитать!Кстати гонка процессов не такая уж редкая вещь, по моему ты изобретаешь велосипед, почитай что нибудь по семафорам.
>>Господа подскажите плз.
>>Есть два процесса, открывших один и тот же файл - первый на
>>чтение, а второй на запись так, что в это же время
>>дописывает данные в конец файла, увеличивая его размер. Необходимо в третьем
>>процессе узнать, в какой точке файла находится читающий процесс для того,
>>
>>чтобы не дать ему наткнуться на конец файла в случае опережения чтения
>>перед записью. Какможно узнать его оффсет?
>>
>>Спасибо!
>
>узнать просто, пусть он который читает, этот офсет выдает, ну к пимеру
>в пайп. можно во временный файл. вообщем как хочешь.
>Я правда так не делал, но вот вопрос, а что такого страшного
>произойдет если этот процесс столкнется с концом файла? как в фильме
>про Ван дама, нельзя было сталкиваться со своим двойником ;-))). Вообщем
>конец файла данных, это еще не конец программы, можно после этого
>поспать и еще раз попробовать прочитать!
>
>Кстати гонка процессов не такая уж редкая вещь, по моему ты изобретаешь
>велосипед, почитай что нибудь по семафорам.
Читающий процесс - это "наружный" видеоплейер, который читает неполный файл и
не может не выдавать мне оффсет и я вставить его не могу в скомпиленый плейер.
Если плейер наткнется на конец файла то он гавкнется, и воспроизведение
прервется, а этого нелдьзя допустить.
Определить время также нельзя, т.к. плейер не в состоянии получить доступ к
сектору индексов которых еще нет (они в конце файла). Необходимо именно
удаленно узнать на каком оффсете он находится.
>Господа подскажите плз.
>Есть два процесса, открывших один и тот же файл - первый на
>чтение, а второй на запись так, что в это же время
>дописывает данные в конец файла, увеличивая его размер. Необходимо в третьем
>процессе узнать, в какой точке файла находится читающий процесс для того,brain core dump т.к. конфликтует с условием задачи о том, что даны два процесса :)
>чтобы не дать ему наткнуться на конец файла в случае опережения чтения
ему - это первому или третьему ? Прочти еще раз сам, ведь это невозможно понять.
>перед записью. Какможно узнать его оффсет?
Это зависит от того, насколько "родственными" по отношению к друг другу являются процессы и того, что действительно необходимо. Навскидку, если все процессы не из серии "черный ящик" и код может быть изменен, то посмотри в сторону flock(2) или fcntl(2) в разделе F_GETLK/F_SETLK. Эти методы самые универсальные в среде UNIX, и большинство задач может быть решено с их использованием. В ряде случаев использование flock будет предпочтительней, хотя с первого взгляда может показаться, что задача не для него. У fcntl/F_(S|G)ETLK могут иногда удивить, если Вы не знаете полной спецификации этого вызова.
P.S. Пожайлуста, пишите о ОС, языке программирования и прочих "незначительных" мелочах. Если Вас действительно волнует, ответят вам, или нет, и насколько исчерпывающим будет ответ.
>P.S. Пожайлуста, пишите о ОС, языке программирования и прочих "незначительных" мелочах. Если
>Вас действительно волнует, ответят вам, или нет, и насколько исчерпывающим будет
>ответ.linux (slackware 10.2)/cpp, простите, сразу не указал.
Да, о том who is who я только что написал в предыдущем ответе. т.е.
читающий процесс это как Вы выразились черный ящик, который я не могу
править (не из программных соображений), я только могу поставить его (плейер)
"на паузу" при подходе к концу файла и когда буфер снова наберется - снять с паузы.
>править (не из программных соображений), я только могу поставить его (плейер)
>"на паузу" при подходе к концу файла и когда буфер снова наберется
>- снять с паузы.Ситуация почти безысходная. Есть один маленький шанс, что плеер может прочитать стандартный ввод. В этом случае это должно выглядеть приблизительно так:
cat /path/to/the/file | player /dev/stdin
В качестве cat /path/to/the/file может использоваться любая другая программа, только запись должна вестись в /dev/stdout соответственно. Если это не поможет, то посмотрите соответсвующие плугины к нему. Кстати, что за плеер ?
>>править (не из программных соображений), я только могу поставить его (плейер)
>>"на паузу" при подходе к концу файла и когда буфер снова наберется
>>- снять с паузы.
>
>Ситуация почти безысходная. Есть один маленький шанс, что плеер может прочитать стандартный
>ввод. В этом случае это должно выглядеть приблизительно так:
>
> cat /path/to/the/file | player /dev/stdin
>
>В качестве cat /path/to/the/file может использоваться любая другая программа, только запись должна
>вестись в /dev/stdout соответственно. Если это не поможет, то посмотрите соответсвующие
>плугины к нему. Кстати, что за плеер ?
mplayer, но его до меня правили и патчей конечно же не оставили. Запускать из конвейера нельзя, потому как для AVI файлов он тогда не сможет выполнять перемотку, а без нее нельзя. Вот и встала задача - при перемотке "вперед" нельзя допустить чтобы плейер налетел на конец файла.
>mplayer, но его до меня правили и патчей конечно же не оставили.
>Запускать из конвейера нельзя, потому как для AVI файлов он тогда
>не сможет выполнять перемотку, а без нее нельзя. Вот и встала
>задача - при перемотке "вперед" нельзя допустить чтобы плейер налетел на
>конец файла.Перемотка вперед, как впрочем и обратно, возможна только в условиях существования конца файла с разметочной информацией для перемотки. В заголовке AVI файла указано смещение, где её можно найти. По вашим словам получается, что файл может существовать с полной разметочной информацией, но не полностью ? ХМ-М-М-М... Тогда предложу решение:
До того, как файл полностью приехал, отсылаются только разметочные данные и заголовок AVI, и на их основе формируется файл с пустыми кадрами небходимой протяженостью. Благо пустые кадры жмутся лучше всего и их можно разместить строго необходимое количество как по кадровке, так и по занимаемому месту. Требование к перезаписывающей программе - чтобы запись велась строго по кадрам V (основной кадр) + N * I (наслоение изменений к кадру). Где N - число наслоений до следующего V кадра. Решение немного кривовато.. а как вы хотели ? :)
>>mplayer, но его до меня правили и патчей конечно же не оставили.
>>Запускать из конвейера нельзя, потому как для AVI файлов он тогда
>>не сможет выполнять перемотку, а без нее нельзя. Вот и встала
>>задача - при перемотке "вперед" нельзя допустить чтобы плейер налетел на
>>конец файла.
>
>Перемотка вперед, как впрочем и обратно, возможна только в условиях существования конца
>файла с разметочной информацией для перемотки. В заголовке AVI файла указано
>смещение, где её можно найти. По вашим словам получается, что файл
>может существовать с полной разметочной информацией, но не полностью ? ХМ-М-М-М...
>Тогда предложу решение:
>
файлы в AVI контейнерах не имеют индексов в конце файла в отличие к примеру от RealVideo,
которые без хвоста не мотаются, и поэтому по мин легко можно делать навигацию, даже
если файл неполный. Это уже проверенный факт.>До того, как файл полностью приехал, отсылаются только разметочные данные и заголовок
>AVI, и на их основе формируется файл с пустыми кадрами небходимой
>протяженостью. Благо пустые кадры жмутся лучше всего и их можно разместить
>строго необходимое количество как по кадровке, так и по занимаемому месту.
>Требование к перезаписывающей программе - чтобы запись велась строго по кадрам
>V (основной кадр) + N * I (наслоение изменений к кадру).
>Где N - число наслоений до следующего V кадра. Решение немного
>кривовато.. а как вы хотели ? :)
Записывающая программа принимает поток от готового, аппаратно сформированного потока,
поэтому ксожалению его менять нельзя.
>файлы в AVI контейнерах не имеют индексов в конце файла в отличие
>к примеру от RealVideo,
>которые без хвоста не мотаются, и поэтому по мин легко можно делать
>навигацию, даже
>если файл неполный. Это уже проверенный факт.Поточный кодек.. Предыдущие посты мне навеяли другое.
>Записывающая программа принимает поток от готового, аппаратно сформированного потока,
>поэтому ксожалению его менять нельзя.Речь идет о MPEG2, или о RAW-Video, или о другом формате ? Если нужна перемотка, то почему не узнать, что за кодек, и пропатчить mplayer еще раз ? Железка - веб камера ? Что за производитель ?
P.S. В ряде случаев можно читать vlc то, что не читается mplayer..
>>файлы в AVI контейнерах не имеют индексов в конце файла в отличие
>>к примеру от RealVideo,
>>которые без хвоста не мотаются, и поэтому по мин легко можно делать
>>навигацию, даже
>>если файл неполный. Это уже проверенный факт.
>
>Поточный кодек.. Предыдущие посты мне навеяли другое.
>
>>Записывающая программа принимает поток от готового, аппаратно сформированного потока,
>>поэтому ксожалению его менять нельзя.
>
>Речь идет о MPEG2, или о RAW-Video, или о другом формате ?
>Если нужна перемотка, то почему не узнать, что за кодек, и
>пропатчить mplayer еще раз ? Железка - веб камера ? Что
>за производитель ?
>
>P.S. В ряде случаев можно читать vlc то, что не читается mplayer..
>
Нет, речь идет об аппаратном кодере видео. Появилась альтернатива использовать xine-libs для воспроизведения этого потока, но в нем я также не нашел интерфейса для доступа к этой информации (скорее всего из-за недосконального знания его :( ). У меня в распоряжении могут быть все переменные, используемые для этого (xine_t, xine_stream_t, xine_audio_port_t, xine_video_port_t). Возможно таким образом определять оффсет в играющем файле?Оптимальный вариант был бы конечно без правки кода ксайна чтобы переход о версии к версии был безболезненным.
>Нет, речь идет об аппаратном кодере видео. Появилась альтернатива использовать xine-libs для
>воспроизведения этого потока, но в нем я также не нашел интерфейса
>для доступа к этой информации (скорее всего из-за недосконального знания его
>:( ). У меня в распоряжении могут быть все переменные, используемые
>для этого (xine_t, xine_stream_t, xine_audio_port_t, xine_video_port_t). Возможно таким образом определять оффсет
>в играющем файле?Модульность большинства плееров вряд ли предусматривает реализацию чтения файла,как отдельного модуля. Скорее всего придется патчить. В принципе это является достаточно простой задачей и легко можно поддерживать.
>Оптимальный вариант был бы конечно без правки кода ксайна чтобы переход о
>версии к версии был безболезненным.Это вряд ли так красиво можно сделать. Альтернатива - попробовать затребовать такой функционал на xine, и передать патч для внесения его в CVS дерево.
>В качестве cat /path/to/the/file может использоваться любая другая программа, только запись должна
>вестись в /dev/stdout соответственно.2>&1 не поможет? :)
Можно попробовать нечто типа:mkfifo FILEO
cat myvideo.dat >FILEO &
BadVideoPlayer FILEO
>Можно попробовать нечто типа:
>
>mkfifo FILEO
>cat myvideo.dat >FILEO &
>BadVideoPlayer FILEO
И что произойдет с плейером когда во время перемотки он дойдет до конца
данных? будет спать пока данные не появятся? и с ним ничего нельзя будет
сделать?
>>Можно попробовать нечто типа:
>>
>>mkfifo FILEO
>>cat myvideo.dat >FILEO &
>>BadVideoPlayer FILEO
>
>
>И что произойдет с плейером когда во время перемотки он дойдет до
>конца
>данных? будет спать пока данные не появятся? и с ним ничего нельзя
>будет
>сделать?Вообще то это тот же pipe. Только именованный. Если mplayer не умеет кешировать данные канала или его не научить этому - то перемотка назад работать не будет.