Поискав "select" в форумах, не нашел чего-то вразумительного...
Потому вопрос: есть два файла, которые необходимо отслеживать. Отслеживать обращение к ним на запись. Приблизительно( по памяти), выглядит так:

int main( int c, char **v ) {
//arg check.. skp

int fd1 = open(v[1], O_RDONLY | O_NONBLOCK ), fd2open(v[2], O_RDONLY | O_NONBLOCK);
//fd open check skp
fd_set readfs;
timeval tv = { 10, 0 };
int ret = 0;

while( 1 ) {
FD_ZERO( &readfs );
FD_SET( fd1, &readfs );
FD_SET( fd2, &readfs );

ret = select( ( fd1 > fd2 ? fd1 : fd2 ) + 1, &readfs, 0, 0, &tv );
if (ret ) {
if( FD_ISSET( fd1, &readfs ) ) //always willb here
if( FD_ISSET( fd2, &readfs ) ) //always willb here
}

Может по коду и напутал чего, но это не принципиально. Когда отдавать ему пустой файл - он сработает. Когда отдать полный - он сработает. Он(select)- всегда сработает, несмотря ни на что. Да что там readfs! Если ему дать writefs с установленными битами дескрипторов - он также будет срабатывать! Вообще, не радоваться, нет повода. Может я чего-то недогоняю... Всегда валидно работало, а с файлами такая-вот "беда".

ps. Текущая реализация этой задачи, работает через PF_UNIX сокеты, но это же не выход, да ? :)

ps. try it in google "man open" :)

• ...и снова select,MaximKuznetsov, 14:01 , 27-Авг-05
• ...и снова select,vnp, 03:09 , 29-Авг-05
  • ...и снова select,qq, 07:44 , 30-Авг-05
    • ...и снова select,vnp, 11:00 , 30-Авг-05
• ...и снова select,Forth, 09:42 , 29-Авг-05
  • ...и снова select,bf_, 16:08 , 29-Авг-05

1) если работа с файлами, то после открытия
переместить указатель в файлах в конец
(man lseek)
2) непосредственно после select обрабатывать ошибки,
то есть конструкция if(ret) сработает и при отрицательном значении ret.
что-то вроде
if (ret<0) {
   /* interrupted call */
   if (errno==EINTR || errno==EAGAIN) {
     clearerr();
     continue;
   }
   error(..);
} else if (ret==0) {
   /* timeout */
} else {
   /* check descriptors */
}
3) внутри цикла while ВСЕГДА устанавливайте значения таймаута,
  потому как после select оно содежит некорректные значения
  ( в linux - сколько времени осталось, но это только в linux)

>Поискав "select" в форумах, не нашел чего-то вразумительного...
>Потому вопрос: есть два файла, которые необходимо отслеживать. Отслеживать обращение к ним
>на запись.

[skip]

>Всегда валидно работало, а с файлами такая-вот "беда".

select не утверждает, что данные есть. select утверждает, что read не заблокируется. При чтении из файла read не блокируется. Никогда. По достижении eof, read немедленно возвращает 0. Ошибка не возникает.

Мораль: с файлами действительно беда.
В скобках - посмотрите на реализацию tail -f

>ps. Текущая реализация этой задачи, работает через PF_UNIX сокеты, но это же
>не выход, да ? :)

Почему?

>select не утверждает, что данные есть. select утверждает, что read не заблокируется.

есть небольшая засада :(

(linux, man select, раздел BUGS)
       Under Linux, select may report a socket file descriptor as "ready  for  reading",  while  nevertheless  a  subsequent  read
       blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There
       may be other circumstances.  Thus it may be safer to use O_NONBLOCK on sockets that should not block.

>>select не утверждает, что данные есть. select утверждает, что read не заблокируется.
>
>есть небольшая засада :(
>
>(linux, man select, раздел BUGS)
>       Under Linux, select may report a socket file descriptor as "ready  for  reading", while  nevertheless  a  subsequent  read
>       blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There
>       may be other circumstances. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

Разумеется. Но проблема обсуждалась другая :(

А на какой системе идет дело? Если кросплатформенность не так принципиальна, то можно привязаться к определенным "фичам".

2 Forth
>А на какой системе идет дело? Если кросплатформенность не так принципиальна, то
>можно привязаться к определенным "фичам".
linux. Если быть точнее 2.2.20

2 vpn
>Мораль: с файлами действительно беда.
>В скобках - посмотрите на реализацию tail -f
Есстественно перед вопросом сюда, я поглядел как делаються файловые мониторы, однако в подавляющем большинстве, были корявые конструкции с таймером, и, по-моему, tail попадал в их число...Хотя могу путаться.

>select не утверждает, что данные есть. select утверждает, что read не >заблокируется. При чтении из файла read не блокируется. Никогда. По >достижении eof, read немедленно возвращает 0. Ошибка не возникает

Верю. В качестве экскурса осталось ядро глянуть

>>ps. Текущая реализация этой задачи, работает через PF_UNIX сокеты, но это же
>>не выход, да ? :)
>Почему?
Выход. Таким образом получился хороший демон журналирования. Это то, на чём я в итоге и остался.

select замечательно работает со всеми устройствами ввода/вывода, но вот просто первый раз, когда я столкнулся с его "отказом".

Спасибо всем ответившим :)