using select() to invoke a timed function

omwoyo · 08-09-2007, 01:25 PM

I am using select to read inputs from more than one connected clients. I have some task to perform every after some given period of time, instead of using a thread or a child process I m not user whether it can be done by the select function.

I am therefore kindly requesting for some advice on how I can manage with select if possible be done

wjevans_7d1@yahoo.co · 08-09-2007, 07:41 PM

You can use function select() to wait for I/O to be occur on one or more file descriptors, and/or wait for a certain amount of time to elapse. I believe this is what you want. For more information:

Code:

man select

Hope this helps.

Hko · 08-10-2007, 06:51 AM

select() does take timeout parameter, so it can be used as a sort of timer also. But as long as the connected client(s) do I/O requests within the timeout period, your periodical task will not run.

If this is not a problem, you could use select()'s timeout parameter.

However on Linux it is possible, using this feature of the Linux version of select(). (from the man page):

Quote:

On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 permits either behavior.) This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for multiple select()s in a loop without reinitializing it.

So, if you don't reset the timeout struct every loop, you could use select() to do this. But it is not portable.

Another way may be to use setitimer().

Note there is also a man page called "select_tut", which is a more tutorial like man page about select(). I suppose they made this because select() is pretty complex to use.

wjevans_7d1@yahoo.co · 08-11-2007, 01:20 AM

Quoth the highly esteemed Hko:

Quote:

select() does take timeout parameter, so it can be used as a sort of timer also. But as long as the connected client(s) do I/O requests within the timeout period, your periodical task will not run.

If this is not a problem, you could use select()'s timeout parameter.

You could use select()'s timeout parameter in any case.

Before you call select(), you should call gettimeofday() to figure out the timeout value to give to select(); the closer you are to when you want to do your next periodic tasks, the lower this timeout value should be. And if the timeout value is zero or negative, you do your periodic tasks before you come back to do select() again.

sundialsvcs · 08-11-2007, 11:42 PM

It can be a bit tricky to cause a select()-based routine to also produce reliable timeouts. You have to use gettimeofday() to establish the current time, then calculate the time-of-day ("deadline") at which the timed-event should next occur, and use this to calculate the appropriate timeout. A check against the deadline must then occur every time through the loop, whether it's being run as a result of timeout or because an I/O-operation was actually completed.

If you have threads at your disposal, it is by far easier to delegate the timed activity to a separate thread, which can concern itself only with the timeout while the select()-processing thread concerns itself only with the select.

wjevans_7d1@yahoo.co · 08-13-2007, 08:15 AM

Quoth the highly esteemed sundialsvcs:

Quote:

It can be a bit tricky to cause a select()-based routine to also produce reliable timeouts. You have to use gettimeofday() to establish the current time, then calculate the time-of-day ("deadline") at which the timed-event should next occur, and use this to calculate the appropriate timeout. A check against the deadline must then occur every time through the loop, whether it's being run as a result of timeout or because an I/O-operation was actually completed.

Pseudocode:

Code:

set initial deadline;

for(;;)
{
  for(;;)
  {
    calculate timeout from deadline;

    if(timeout>0)
    {
      break;   /* <--------- */
    }

    do the timed event;

    deadline+=interval;
  }

  select();

  if(any I/O completed)
  {
    respond to one I/O event;
  }

  /* No special reaction to timeout. */
}

I guess what I'm missing is what's tricky about this.

My experience with threads is that you avoid them if you can, and use them when you must. Since all threads share the same memory space, debugging can be a huge pain, especially when encountering memory corruption problems.