ramalaks
asked on
CPU time for poll
When select is used with readfds and writefds, the exe occupies lot of CPU time. When monitored using the prof, it says poll and select takes lot of time. when writefds is removed, It does not occupy CPU resouces. Why is it so? Am I forgetting something else inorder to have writedfds also to be polled in select?
ASKER
in main,
.....
while(1)
{
nready = select(maxfds+1, &readFds, &writeFds, NULL,&tm); /* tm val is 1 sec */
if (nready > ) {
take actions....
}
} /*for while loop */
I do not have any poll in my code. The prof gives select and _poll with 80% of the CPU time.
.....
while(1)
{
nready = select(maxfds+1, &readFds, &writeFds, NULL,&tm); /* tm val is 1 sec */
if (nready > ) {
take actions....
}
} /*for while loop */
I do not have any poll in my code. The prof gives select and _poll with 80% of the CPU time.
Why did you set the time to 1 sec. You can have a large time interval here. The select system call will automatically return if one of the descriptor has got some signal.
From looking at your code, I have a couple of observations/suggestions:
1. Try using the FD* macros defined in one of the system header files (sys/time.h on HP-UX 10.20): i.e. FD_SETSIZE, FD_ZERO, FD_SET, FD_ISSET.
2. The timeout variable for HP-UX is specified in the man page as a "struct timeval". The variable name you use, "tm", leads me to suspect you're using a struct tm. Is this correct for your platform? If not, it could be causing select to return too quickly.
Let me know if this makes any difference.
Anju
1. Try using the FD* macros defined in one of the system header files (sys/time.h on HP-UX 10.20): i.e. FD_SETSIZE, FD_ZERO, FD_SET, FD_ISSET.
2. The timeout variable for HP-UX is specified in the man page as a "struct timeval". The variable name you use, "tm", leads me to suspect you're using a struct tm. Is this correct for your platform? If not, it could be causing select to return too quickly.
Let me know if this makes any difference.
Anju
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
For basant,
I will try increasing the tm value to 5 sec and see what happens.
For Anju,
What I had given was sample/pseudo code. I am using FD_SET, CLR, ISSET macros for setting and clearing .etc
And also my "tm" is of type struct timeval which is a system defined struture.
The code you have given looks like what I am tring to do. You may be right in setting the write fd only when I have something to write. I have not added that in my code.
I will try making those changes and see what happens. thanks for the comment to both of you.
I will try increasing the tm value to 5 sec and see what happens.
For Anju,
What I had given was sample/pseudo code. I am using FD_SET, CLR, ISSET macros for setting and clearing .etc
And also my "tm" is of type struct timeval which is a system defined struture.
The code you have given looks like what I am tring to do. You may be right in setting the write fd only when I have something to write. I have not added that in my code.
I will try making those changes and see what happens. thanks for the comment to both of you.
ASKER
It seems to be working if I set the writeFds only when I want to write. Otherwise, the select will return immidiately with alway writeFds set which happens always and the loop goes on like this forever which takes more CPU time.
Points to anju.
thanks.
Points to anju.
thanks.
Just a couple more short tips. You may already know them, but perhaps not. If not, they could possibly save you hours or even days of trouble...
After the problems youv'e just experienced, you might be led to think that a file descriptor is always writeable and be tempted to simply exclude it from the select mask all of the time. Don't do that! For example, if the fd is a socket, the send buffer could become full. If this happens, a write could fail, or worse, it could block depending upon the socket options you've set. Always map it into the select mask just prior to writing to it.
Another thing is that you can "peek" at the buffer of a fd which has a read pending and find out how many bytes are available for reading. To do this, see the man page for ioctl, and in particular, the FIONREAD option:
int nBytes;
ioctl( fd, FIONREAD, &nBytes );
Last, if you're communicating simple line-based text via sockets or serial ports, consider using line mode. You can use ioctl to set options on the socket which will cause the kernel to only wake up select for a readable fd when there is a full line of text in the buffer. This prevents you from having to read partial lines and paste them together all the time. See the ioctl man pages (man -k ioctl) for details.
Good luck!
After the problems youv'e just experienced, you might be led to think that a file descriptor is always writeable and be tempted to simply exclude it from the select mask all of the time. Don't do that! For example, if the fd is a socket, the send buffer could become full. If this happens, a write could fail, or worse, it could block depending upon the socket options you've set. Always map it into the select mask just prior to writing to it.
Another thing is that you can "peek" at the buffer of a fd which has a read pending and find out how many bytes are available for reading. To do this, see the man page for ioctl, and in particular, the FIONREAD option:
int nBytes;
ioctl( fd, FIONREAD, &nBytes );
Last, if you're communicating simple line-based text via sockets or serial ports, consider using line mode. You can use ioctl to set options on the socket which will cause the kernel to only wake up select for a readable fd when there is a full line of text in the buffer. This prevents you from having to read partial lines and paste them together all the time. See the ioctl man pages (man -k ioctl) for details.
Good luck!
Can u post some code or psuedo code what r u doing.