Alarm(2) - 当有人在等待时更改系统时间时，它会做什么？
手册页显示 alarm() 安排在 _seconds_ 秒内将 SIGALRM 信号传递给进程。如果某人（例如用户或 ntpd）发生更改，会发生什么情况闹钟待处理时的系统时钟？警报的剩余时间是如何计算的？
The man page says that alarm() arranges for a SIGALRM signal to be delivered to the process in _seconds_ seconds. What happens if someone (such as the user or ntpd) changes the system clock while the alarm is pending? How is the time remaining on the alarm accounted for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，大多数负责任的管理员和 xntpd 通常不会大幅调整时间。例如，这样做会破坏 cron。
但即使他们要这样做，警报也会使用 setitimer() 和 ITIMER_REAL - 这意味着它仍然会
等待这么多时钟滴答声。假设系统时钟以 100 万赫兹（每秒 100 万个滴答声）运行。好的，所以 2 秒就是 200 万个实时时钟滴答声，无论系统时间设置为多少。 setitimer() 只是继续将其计数器递减至零。当它达到零时，SIGALARM 被引发。由于其他进程可能拥有 CPU，因此在较长的一段时间内可能会有相当大的空闲时间。 Alarm() 保证在最短 n 秒内触发 - 实际经过的时间可能会更长一些。
弄乱系统时间会破坏 AppWorx 或 cron 等调度软件。
First off, most responsible admins and xntpd are certainly not normally going to adjust time in huge chunks. Doing that breaks cron, for example.
But even if they were to do that, alarm uses setitimer() with ITIMER_REAL - meaning it would still
wait for so many clock ticks. Pretend the system clock runs at 1 million Hz, one million ticks per second. Okay, so 2 seconds is 2 million realtime clock ticks, regarldess of what the system time is set to. setitimer() just keeps on decrementing its counter to zero. When it hits zero, SIGALARM is raised. There can be considerable slack on long side of this because other processes could have the cpu. alarm() is guaranteed to go off in a MINUMUM of n seconds - the actual elapsed time could be a little longer.
Messing with system time breaks scheduling software like AppWorx or cron.