Simple way for exiting programs with power button without showing the screensaver

[NullNix]

Originally Posted by Aeris

Does anybody know how much resources does sleep function consume (CPU and RAM mainly)? I've googled but didn't find nothing... are so low to be completely neglectable?

Sleeping consumes no CPU time, and minimal memory. From a userspace perspective, all sleeps -- like all hardware access -- simply involve a call into the kernel, where the process blocks (consuming no CPU) until awoken. From a kernel perspective, all these events involve putting the task (not 'process' at this level) into a waitqueue, which is traversed and waiting tasks awoken only when the conditions for awakening are right. So, total memory hit: one kernel stack (always consumed whenever the process exists, but worth noting) and one pointer on a waitqueue somewhere in the kernel.

So, basically, sleeping is as close to nil overhead as anything ever is.

[NullNix]

Originally Posted by twobob

from what I can figure the process is put into a "sleep" state (see htop, the processes marked S are sleeping) and then (depending if the usleep or sleep command) is used they are subsequently triggered by a "type of" signal. (this /may/ be the "alarm" signal)

I am also relatively certain this is achieved by the use of http://man7.org/linux/man-pages/man2...meofday.2.html mixed with http://man7.org/linux/man-pages/man2/alarm.2.html , but as I intimated above usleep is guaranteed to fire - whereas "sleep" is a bit more sketchy

strace usage often reveals MANY gettimeofday calls inside apps, and I have always thought that this was /probably/ related to sleeping processes.

In terms of resource I would list it as "negligible"

Hopefully someone can back-up or pooh-pooh what I have said here as it is mainly conjecture.

Close! As with many old Unix things this is a bit of a nest of snakes -- it could be worse, it's not terminal I/O, now *that* is a horror.

The original Unix way of sleeping was, indeed, sleep(3). This was implemented by setting an alarm with alarm(2) and then waiting for the SIGALRM via pause(2). Over time, signals got more and more complex in a desperate attempt to make them reliable, so in the end this was more of a block/alarm/unblock dance. But still it was restricted to 1s increments.

And then people looked at this and thought, this is ridiculous, why can't we sleep for less than one second? So the BSD people implemented usleep(), which worked in much the same way but allowed shorter sleeps: internally this was implemented via the new ualarm() syscall. Then POSIX came along, and now usleep() is obsolete and we have nanosleep() instead. This is a syscall in its own right, so we no longer need to futz around with signals and worry about multiple threads going to sleep at the same time and colliding with each other and generally go into spasms of hair-tearing, as one does whenever signals are involved.

This was back in 1993, and it was good enough for a while. POSIX.1-2001 improved on this, specifying a bunch of clock_*() calls to get and set the time with far more flexibility than good old gettimeofday(), which while useful (it is the most commonly called syscall on Linux systems by a wide margin) is not ideal, because gettimeofday() only gives you wall clock time, which can jump back and forward and the like: clock_gettime() can give you a monotonically increasing clock, an uptime clock, and many others. They added a clock_nanosleep() too, which can sleep for a given time in realtime, in monotonic nanoseconds (so not thrown off if the system clock is changed) and even in process-wide CPU time.

We also now have a timer_*() API, which lets you set up arbitrarily many one-shot or multi-shot timers, which can signal their firing in numerous ways. This is really, really useful, and so complicated that I haven't yet encountered anyone who uses it unless forced.

(Obviously, there are manpages for all of these.)

As for why gettimeofday() is so frequently called -- because if you need to impose an ordering on something, the easiest way to do it is to attach a timestamp to it. And gettimeofday() is *fast*, and will always be fast, because X attaches a timestamp to every single X event, and you get a long stream of those whenever you move your mouse across the screen.

[brianinmaine]

wonderful reading! thanks!

[knc1]

Quote: "gettimeofday() is **fast**"

You better believe it.
That statement has an interesting story all its own.

Far too long for a forum post but can probably be found somewhere in the development history of *nix or computer OSs in general.

For performance critical code paths, it is (still) common for those to be hand-coded and cycle counted - -
And then there is "gettimeofday()" -

This one is where both software implementors and cpu hardware implementors start doing crazy dances and hand-springs.
And they start considering hardware delay paths within a single clock cycle.
Where referencing an off-chip memory location or off-chip register location is: "too much overhead".

Yes, "gettimeofday() is **fast**"