Quote:
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.