> > Может использовать thread'ы, а не форкаться? Как бы тут на них не ругались, > > что они не вписываются в архитектуру Unix, но работать с ними можно > > всё-таки. > вроде насколько я читал (правда это относительно давно было) треды через > те же форки в линуксе организованы 1) ИМХО, с появлением NPTL это уже не так. 2) Во-вторых, всё-таки у потоков адресное пространство одно и тоже, и никакого отложенного копирования страниц там не возникает.
> > Кроме того, возможно у тебя ещё происходит копирование из kernel-space в > > user-space. > чтение из девайса? ну да > но тут если оптимизировать - модульность смажется > будет не программа а гнусный хак ;) > > > Если ты можешь править драйвер, но покури доку, кажется, на > > relayfs - его, по-моему, как раз придумали для того, чтобы этого избежать. > > это в смысле драйвер может предоставить свои буфера для чтения чтоли? > сейчас поищу доку > > > > PS: смотрел я как работает система - максимум дочек накапливается около > > > 20 штук, то есть скорость потока "пляшет", однако интегральный запас ОЗУ > > > получается очень большим. > > В принципе, я думаю, что можно обойтись двумя нитями, одна читает, другая > > пишет. > то есть у той что пишет - очередь данных на входе? > получается копирований данных может еще больше чем в моем случае > получиться :) Почему только у той, что пишет? У той что читает тоже таже очередь. Только одна нить ставит, другая снимает. Доступ к очереди на изменение контролируется каким-нить семафором (его значение можно интерпретировать как кол-во блоков в очереди), либо мьютексом. Ну естественно в очереди хранятся только указатели на блоки, поэтому никаких копирований больше не возникает. ЗЫ: Посмотри как делают буферные дескрипторы, по-моему, задача того же рода. -- Макс -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
