alarm works without active waiting,
Since the advent of SAFE_SIGNALS; alarm won't interrupt long running opcodes.
And the cpu requirement of the "active waiting" -- waking 1 per second:
C:\test>perl -E"sleep 1 for 1..120; say join ' ', times"
0 0.015 0 0
0.015/120 = 0.0125% cpu usage; means that it would require 8000 of these actively waiting tasks to even register a blip on a cpu usage graph.
sleep 1 does not always sleep exactly one second.
On modern OSs, the differences are tiny -- essentially the time taken between the 1 second elapsing and the process getting its next time-slice:
C:\test>perl -MTime::HiRes=time -E"$t=time; sleep 1 for 1 .. 10*60; pr
+int (time()-$t) - 10*60"
601.386687040329 - 600 / 600 = 0.002311145067215. A couple of milliseconds
Which means that after 10 minutes of waiting, those tiny differences will have accumulated such that you've ended up giving the user a whole extra second in which to respond. Big deal.
But the kicker is: alarm will suffer from the essentially the same delays and inaccuracies! Once the system timer times out and sets the flag in the kernel thread structure; it still won't run until it filters its way to the top of the schedulers list of run-eligible threads.
Re-reading the post to which you responded and the OP; the former is almost certainly not a solution to the latter -- but definitely not because of the reasons you cite. They are just sweating the small stuff whilst ignoring the bigger picture.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.