Thread: select with time out zero (in Linux? in Windows?)

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    select with time out zero (in Linux? in Windows?)

    I need this info please not only for Linux C pthreads but also for Microsoft Visual Studio 2005

    If one calls select() (only wit a read set of file descriptors) with a timeout zero does that ensure a "net" (clean) non blocking behaviour? That is: if no fd of the set is ready for reading, does select return immediately (only after the time necessary to perform the necessary checks) or does it yield the processor and might take several msec to get the processor back if other threads (with same priority) were ready to run? In other words does it happen something similar to what would happen if i called sleep() wit a few nanosec argument?

    Thank you

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    As far as I know the behavior is the same on Linux and Windows: With a zero timeout, the call will immediately return, although if your thread's timeslice is expiring you will of course be switched out until the next timeslice.

    Except under certain realtime circumstances, it is NEVER guaranteed that you will return immediately (as far as wall clock time) because you could always be scheduled out. But that's usually not a concern.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by brewbuck View Post
    As far as I know the behavior is the same on Linux and Windows: With a zero timeout, the call will immediately return, although if your thread's timeslice is expiring you will of course be switched out until the next timeslice.

    Except under certain realtime circumstances, it is NEVER guaranteed that you will return immediately (as far as wall clock time) because you could always be scheduled out. But that's usually not a concern.
    ok so it does not happen smething similar to sleep() where, despite of the arg. being specified in nanosec, you have to wait in any case for the time resolution given by the HZ kernel parameter, which can be 10 msec in older kernels or 1 msec in later kernels with HZ=1000 ?

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by mynickmynick View Post
    ok so it does not happen smething similar to sleep() where, despite of the arg. being specified in nanosec, you have to wait in any case for the time resolution given by the HZ kernel parameter, which can be 10 msec in older kernels or 1 msec in later kernels with HZ=1000 ?
    Generally speaking, zero would mean "no timeout", not "one clock tick". Values above zero may be rounded up.

    I may have a look to see if I can find some source to check out if it really does that.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mynickmynick View Post
    ok so it does not happen smething similar to sleep() where, despite of the arg. being specified in nanosec, you have to wait in any case for the time resolution given by the HZ kernel parameter, which can be 10 msec in older kernels or 1 msec in later kernels with HZ=1000 ?
    If you specify a non-zero timeout this timeout will usually be rounded up to the scheduler's resolution. By nature, the kernel cannot schedule in units smaller than a clock tick because this is its only conception of time.

    A kernel could choose to busy-wait (spin) in order to implement very small delays, but this is generally not preferred because it wastes processor time.

    In Linux, when a non-preemptible system call returns the kernel will check to see if a time slice has expired, and if so, invokes the scheduler. But this is completely out of your control whether you specify a zero timeout or not. The important thing is that your process will not block at all, in terms of process time, but not in terms of wall time.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Yes, as brewbuck states, zero means "no timeout". Check out this:
    http://fxr.watson.org/fxr/source/fs/...v=linux-2.4.22
    Particularly lines around 218.

    Ok, so it's for Linux kernel 2.4.22, but I expect it's same or similar in newer versions of Linux. If timeout is zero, then it doesn't do a timeout, it just returns.

    This is of course BAD to do in an application unless you perform sleep or something else elsewhere in the code - as you will use 100% cpu to do nothing.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    Yes, as brewbuck states, zero means "no timeout". Check out this:
    http://fxr.watson.org/fxr/source/fs/...v=linux-2.4.22
    Particularly lines around 218.

    Ok, so it's for Linux kernel 2.4.22, but I expect it's same or similar in newer versions of Linux. If timeout is zero, then it doesn't do a timeout, it just returns.
    thank you

    This is of course BAD to do in an application unless you perform sleep or something else elsewhere in the code - as you will use 100% cpu to do nothing.

    --
    Mats
    yes of course

  8. #8
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    Ok, so it's for Linux kernel 2.4.22, but I expect it's same or similar in newer versions of Linux. If timeout is zero, then it doesn't do a timeout, it just returns.

    --
    Mats

    sorry (I had a fast look so there is a good chance I misread) but if you go through the interesting link you gave it seems that inside

    408 signed long schedule_timeout(signed long timeout)

    at http://fxr.watson.org/fxr/source/ker...gexcerpts#L408

    (this function is called by do_select which is called by sys_select)

    it does

    expire = timeout + jiffies;

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    However, if we read the code I pointed to:
    Code:
    218                 if (retval || !__timeout || signal_pending(current))
    219                         break;
    220                 if(table.error) {
    221                         retval = table.error;
    222                         break;
    223                 }
    224                 __timeout = schedule_timeout(__timeout);
    225         }
    Line 219 says "break", which means break the for-loop that ends on line 225 - so it will jump to line 226 when you hit that break. Since !__timeout is true if timeout is zero, it will never get to schedule_timeout(). So it doesn't actually matter what happens in schedule_timeout(), since it is never executed when timeout is zero.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    However, if we read the code I pointed to:
    ...
    Line 219 says "break", which means break the for-loop that ends on line 225 - so it will jump to line 226 when you hit that break. Since !__timeout is true if timeout is zero, it will never get to schedule_timeout(). So it doesn't actually matter what happens in schedule_timeout(), since it is never executed when timeout is zero.

    --
    Mats
    ok !!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. pthread and socket porting from Linux to Windows
    By mynickmynick in forum C Programming
    Replies: 2
    Last Post: 07-18-2008, 06:57 AM
  2. Linux vs Windows
    By manav in forum A Brief History of Cprogramming.com
    Replies: 114
    Last Post: 04-08-2008, 08:32 AM
  3. Erm...so what DOES Linux do that Windows doesn't?
    By 7smurfs in forum Tech Board
    Replies: 19
    Last Post: 09-09-2005, 03:04 PM
  4. Linux for Windows!
    By Strut in forum Linux Programming
    Replies: 2
    Last Post: 12-25-2002, 11:36 AM
  5. Linux? Windows Xp?
    By VooDoo in forum Linux Programming
    Replies: 15
    Last Post: 07-31-2002, 08:18 AM