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.
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 ?
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.
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.
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.
yes of course
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.
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;
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.
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.
ok !!
C++ Tutorial
5 ways you can learn to program faster
The 5 Most Common Problems New Programmers Face
How to set up a compiler
8 Common programming Mistakes
What is C++11?
Creating a game, from start to finish
Recent additions
How to create a shared library on Linux with GCC
- December 30, 2011
Enum classes and nullptr in C++11
- November 27, 2011
Learn about The Hash Table
- November 20, 2011
Rvalue References and Move Semantics in C++11
- November 13, 2011
C and C++ for Java Programmers
- November 5, 2011
A Gentle Introduction to C++ IO Streams
- October 10, 2011
