select() problem/feature

select() problem/feature

[Nikola]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Hi all,

i am writing small daemon.....and when i was seeing the end ......that 
was just the beginning
of my problems.

General idea was to monitor list of files that was given on start.

For this example i am using test1.txt and test2.txt because I've 
succeeded to replicate my problem
,at least i think so....:)))))

so the files are....

test1.txt
-----8<-----8<-----8<-----8<-----8<-----8<-----8<
Testing from test1
-----8<-----8<-----8<-----8<-----8<-----8<-----8<



test2.txt
-----8<-----8<-----8<-----8<-----8<-----8<-----8<
Testing from test1
-----8<-----8<-----8<-----8<-----8<-----8<-----8<

and daemon.c


Now the problem is following:

when i compile (gcc daemon.c => a.out) and run binary in this version 
all works fine....and
if I do
#echo "some new line" >> test1.txt

i would see on my screen that select figured it out and i am having new 
data for processing and it
would print it out.

but when i uncomment last fprintf my while and select goes 
ballistic.....it prints  numbers forever...not
blocking......

So why is that this line "fprintf(stderr,"%d\n",i++);" causes this behavior.

tnx for help.

[-- Attachment #2: daemon.c --]
[-- Type: text/x-csrc, Size: 879 bytes --]

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/select.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {

 	FILE *fp1,*fp2;
	fd_set fdst;
	char buffer[100];
	int i;
	
	
	if((fp1 = fopen("test1.txt","r")) == NULL){
		return 0;
	}
	
	if((fp2 = fopen("test2.txt","r")) == NULL){
		return 0;
	}
	
	
	
        /* Daemon-specific initialization goes here */

        /* The Big Loop */
        while (1) {
           /* Do some task here ... */

		FD_ZERO(&fdst);
		FD_SET(fileno(fp1),&fdst);
		FD_SET(fileno(fp2),&fdst);

		select(fileno(fp2)+1,&fdst,NULL,NULL,NULL);

		
		if(FD_ISSET(fileno(fp1),&fdst)){

			while(fgets(buffer,100,fp1) != NULL){
				puts(buffer);

			}	
		}
		

		if(FD_ISSET(fileno(fp2),&fdst)){
			
			while(fgets(buffer,100,fp2) != NULL){
				puts(buffer);
			}	
	
		}

		//fprintf(stderr,"%d\n",i++);
	
        }
	
	exit(EXIT_SUCCESS);
}

Re: select() problem/feature

[Mihai Dontu]

Nikola wrote:
> Hi all,
> 
> i am writing small daemon.....and when i was seeing the end ......that 
> was just the beginning
> of my problems.
> 
> General idea was to monitor list of files that was given on start.
> 
> For this example i am using test1.txt and test2.txt because I've 
> succeeded to replicate my problem
> ,at least i think so....:)))))
> 
> so the files are....
> 
> test1.txt
> -----8<-----8<-----8<-----8<-----8<-----8<-----8<
> Testing from test1
> -----8<-----8<-----8<-----8<-----8<-----8<-----8<
> 
> 
> 
> test2.txt
> -----8<-----8<-----8<-----8<-----8<-----8<-----8<
> Testing from test1
> -----8<-----8<-----8<-----8<-----8<-----8<-----8<
> 
> and daemon.c
> 
> 
> Now the problem is following:
> 
> when i compile (gcc daemon.c => a.out) and run binary in this version 
> all works fine....and
> if I do
> #echo "some new line" >> test1.txt
> 
> i would see on my screen that select figured it out and i am having new 
> data for processing and it
> would print it out.
> 
> but when i uncomment last fprintf my while and select goes 
> ballistic.....it prints  numbers forever...not
> blocking......
> 
> So why is that this line "fprintf(stderr,"%d\n",i++);" causes this 
> behavior.
> 
> tnx for help.
> 
> 
> ------------------------------------------------------------------------
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/select.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(void) {
> 
>  	FILE *fp1,*fp2;
> 	fd_set fdst;
> 	char buffer[100];
> 	int i;
> 	
> 	
> 	if((fp1 = fopen("test1.txt","r")) == NULL){
> 		return 0;
> 	}
> 	
> 	if((fp2 = fopen("test2.txt","r")) == NULL){
> 		return 0;
> 	}
> 	
> 	
> 	
>         /* Daemon-specific initialization goes here */
> 
>         /* The Big Loop */
>         while (1) {
>            /* Do some task here ... */
> 
> 		FD_ZERO(&fdst);
> 		FD_SET(fileno(fp1),&fdst);
> 		FD_SET(fileno(fp2),&fdst);
> 
> 		select(fileno(fp2)+1,&fdst,NULL,NULL,NULL);
> 
> 		
> 		if(FD_ISSET(fileno(fp1),&fdst)){
> 
> 			while(fgets(buffer,100,fp1) != NULL){
> 				puts(buffer);
> 
> 			}	
> 		}
> 		
> 
> 		if(FD_ISSET(fileno(fp2),&fdst)){
> 			
> 			while(fgets(buffer,100,fp2) != NULL){
> 				puts(buffer);
> 			}	
> 	
> 		}
> 
> 		//fprintf(stderr,"%d\n",i++);
> 	
>         }
> 	
> 	exit(EXIT_SUCCESS);
> }
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 

1st: you can not use select on fd-s opened on regular files; use aio for
async. I/O;

2nd: leave the comment on. check the CPU - if I'm not mistaking, the
while(1){} goes nuts with or without fprintf();

M.D.


-- 
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://www.bitdefender.com/

Re: select() problem/feature

[Glynn Clements]

Nikola wrote:

> i am writing small daemon.....and when i was seeing the end ......that 
> was just the beginning
> of my problems.
> 
> General idea was to monitor list of files that was given on start.

> if I do
> #echo "some new line" >> test1.txt
> 
> i would see on my screen that select figured it out and i am having new 
> data for processing and it
> would print it out.

select() is of no use here; files are always "ready" for I/O. select()
is intended for use on descriptors where I/O calls may block
indefinitely: pipes, sockets, terminals and other "slow" character
devices.

You can either poll the file at intervals (like "tail -f ..." does),
or use the linux-specific "dnotify" ioctl()s (see the file
Documentation/dnotify.txt in the kernel source tree for details).

> but when i uncomment last fprintf my while and select goes 
> ballistic.....it prints  numbers forever...not
> blocking......

None of the syscalls in your code will ever block; your program will
be running continuously, using up to 100% CPU. Uncommenting the
fprintf() call simply makes this obvious; it isn't changing anything.

-- 
Glynn Clements <glynn@gclements.plus.com>