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?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I don't think "select" takes that much time. However polling may be costly depend on the fequency.
Can u post some code or psuedo code what r u doing.
ramalaksAuthor Commented:
in main,



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.
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

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.

One more thing.  You should only map in writefds when you actually want to write something.  Otherwise, select will return immediately if any of the writefds is writeable, which will most likely be all the time.  Example:

int myReadFDs[2], myWriteFDs[2];
int nFDs = ((sizeof(myReadFDs)/sizeof(int));

.... // open fds

while (1)
  int nReady;
  fdset sRead, sWrite;
  struct timeval sTimeout;

  sTimeout.tv_sec = 5;  // 5 Sec
  sTimeout.tv_usec = 0; // 0 uSec


  for (iFD=0; iFD<nFDs; iFD++)
    // Always map read FDs
    FD_SET(myReadFDs[iFD], &sRead);

    // Map write FDs only if write pending
    if (WritePending(myWriteFDs[iFD]))
      FD_SET(myWriteFDs[iFD], &sWrite);

    nReady = select( FD_SETSIZE, &sRead, &sWrite, NULL, &sTimeout);
    // Check for signal interruption
    if (nRead == -1)
      if (errno == EINTR)
        continue;  // restart select

  for (iFD=0; iFD<nFDs; iFD++)
    if (FD_ISSET(myReadFDs[iFD], &sRead))
      HandleRead( myReadFDs[iFD] );
    if (FD_ISSET(myWriteFDs[iFD], &sWrite))
      HandleWrite( myWriteFDs[iFD] );

  ... // Other processing


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ramalaksAuthor Commented:
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.
ramalaksAuthor Commented:
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.
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!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.