Hi Werner,
> > I wonder if aiming for dead on the second is a good idea. If
> > everything did that then there might silence until the next second
> > boundary, but many cores would wake up to work for a short time.
>
> I had the same concern but the folks who suggested that said that this
> is the best strategy for short term jobs. Apparently cron et all work
> the same.
Here on Arch Linux, /usr/bin/crond is owned by cronie 1.5.1-1, and it
sleeps for 60 s exactly, slowly creeping forwards. The sleep is
sometimes interrupted by SIGCHLD, but that's very soon after it's
started and the 59.xxx s remaining that its told is left becomes another
60 s sleep.
$ sudo -i strace -tt -e nanosleep -p `pidof crond`
strace: Process 303 attached
16:09:01.325441 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:10:01.326133 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:11:01.326724 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:12:01.327254 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:13:01.327842 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:14:01.328426 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:15:01.329013 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:16:01.329637 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:17:01.330289 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:18:01.330832 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:19:01.331389 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:20:01.332925 nanosleep({tv_sec=60, tv_nsec=0}, {tv_sec=59,
tv_nsec=732892671}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
16:20:01.600374 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED,
si_pid=27903, si_uid=0, si_status=0, si_utime=1, si_stime=0} ---
16:20:01.600779 nanosleep({tv_sec=60, tv_nsec=0}, 0x7fff5d22ac50) = 0
16:21:01.601394 nanosleep({tv_sec=60, tv_nsec=0},
Any thoughts on my other points in the earlier email
https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057745.html
that talks about avoiding some of the wake ups altogether?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
