|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 24 Jan 2003 10:57:53
To : Kirill Frolov
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
>>> Kirill Frolov wrote:
ZK>>> переназначение. Видел однажды исходник, там был трюк с _закрытием_
ZK>>> stdout и открытием "трубы". В результате открываемый дескриптор
ZK>>> попадал на "первое свободное" место, то есть как раз на место
ZK>>> закрытого стандартного вывода и становился стандартным выводом.
ZK>>> Вот только не знаю, насколько подобные предположения правомерны -
ZK>>> всегда ли это сработает.
VN>> Правомерны. Использование первого свободного дескриптора гарантируется
VN>> Posix, поэтому если 0 занят, а 1 только что закрыли, то open() отдаст
VN>> или ошибку, или 1. Вот грабля тут есть - не всегда close() завершается
VN>> успешно с закрытием дескриптора, бывают (хотя крайне редко) и более
VN>> извратные позы.
KF> А почему просто не сделать
KF> open(труба); close(stdin); dup2(труба, stdin); close(труба) ?
KF> :-/
Во-первых, не stdin (это объект stdio, типа FILE*), а 0 или STDIN_FILENO
(если есть такая константа).
Во-вторых, здесь у тебя лишний dup2. А если ты закрыл 0, то имеешь
гарантию на то, что: "Если файл будет открыт, то его дескриптор будет равен 0".
Так почему бы этим не воспользоваться?
ZK>>> работать может если график простой! Hадо только озаботиться
ZK>>> синхронизацией, чтобы не "перекормить" гнуплот данными.
VN>> Во-во.
KF> Опять не понимаю чего-то -- буфер там же не бесконечный?
KF> Перекормится и первая программа заблокируется на записи. Можно в
KF> NON_BLOCKING открыть и смотреть сколько записалось. Или я в чём-то ошибаюсь?
Мне кажется, что gnuplot такого вообще не требует, он более детерминирован.
Hо это если всегда знаешь, где конец ответа.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
