1. 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
   [download]

   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.

2. 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
   [download]

   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.