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

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.

Quote:

---

Originally Posted by brewbuck

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 ?

Quote:

---

Originally Posted by mynickmynick

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

Quote:

---

Originally Posted by mynickmynick

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.

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

Quote:

---

Originally Posted by matsp

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

Quote:

---

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

Quote:

---

Originally Posted by matsp

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;

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

Quote:

---

Originally Posted by matsp

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 !!