18 ms·

Their point is a valid one though. I don't really think the init process is the right place for timers.

by DC-3 8y ago

derefr 8y ago
Maybe you've never tried to optimize an OS for battery life on mobile devices, then. There needs to be one place that timers happen—ideally the kernel, but a "userland kernel adjunct" like systemd is fine too—in order to be able to coalesce all the timers on the system (except for real-time ones) along some granularity scale. You don't want to go to all the effort to spin up a CPU core to schedule a (cron) process thread, just to find out it has no work to do. Ideally, if you're going to check the time at all, you just want it done in one thread running on one core, so that the rest of the cores can stay asleep and you never have to spend energy context-switching when idle. That being said, systemd isn't quite the right architecture for getting down to a "tickless everything" system. That'd be something more like WinNT's kernel timer object API, where the kernel sends an event to your window's or service's message inbox to wake you up when the timer is done; or macOS's "Grand Central Dispatch", where any native code (including non-Foundation POSIX code!) can pass scheduling control of any async block through a Mach trap over to one central scheduling process, which coalesces both timers and the runtimes of async events in general so that all background CPU activity happens in bursts with idles in between.
theamk 8y ago
In my cronjob, I like to log the target process output, and ensure that only one timer jobs runs at a time, and apply resource limits, and have an easy way to know if the job is still running. Right now, I am doing this all with a mess of shell scripts (flock + logger + echo calls + pgrep). This is fragile and ugly. Since systemd provides all of the above easily, a better approach will be one-off systemd jobs. In this case, my crontab entries would be a trivial -- "1 3 * * * root systemctl start cronjob1". This only requires scheduling functionality -- background execution, env vars, email notification and other things no longer matter. From there, it is just one small step to move scheduling into the init process itself -- after all, compared to what other things init does, scheduling is both simple and safe.

Their point is a valid one though. I don't really think the init process is the right place for timers.

by DC-3 8y ago

Their point is a valid one though. I don't really think the init process is the right place for timers.

Maybe you've never tried to optimize an OS for battery life on mobile devices, then. There needs to be one place that timers happen—ideally the kernel, but a "userland kernel adjunct" like systemd is fine too—in order to be able to coalesce all the timers on the system (except for real-time ones) along some granularity scale. You don't want to go to all the effort to spin up a CPU core to schedule a (cron) process thread, just to find out it has no work to do. Ideally, if you're going to check the time at all, you just want it done in one thread running on one core, so that the rest of the cores can stay asleep and you never have to spend energy context-switching when idle. That being said, systemd isn't quite the right architecture for getting down to a "tickless everything" system. That'd be something more like WinNT's kernel timer object API, where the kernel sends an event to your window's or service's message inbox to wake you up when the timer is done; or macOS's "Grand Central Dispatch", where any native code (including non-Foundation POSIX code!) can pass scheduling control of any async block through a Mach trap over to one central scheduling process, which coalesces both timers and the runtimes of async events in general so that all background CPU activity happens in bursts with idles in between.

theamk 8y ago

In my cronjob, I like to log the target process output, and ensure that only one timer jobs runs at a time, and apply resource limits, and have an easy way to know if the job is still running. Right now, I am doing this all with a mess of shell scripts (flock + logger + echo calls + pgrep). This is fragile and ugly. Since systemd provides all of the above easily, a better approach will be one-off systemd jobs. In this case, my crontab entries would be a trivial -- "1 3 * * * root systemctl start cronjob1". This only requires scheduling functionality -- background execution, env vars, email notification and other things no longer matter. From there, it is just one small step to move scheduling into the init process itself -- after all, compared to what other things init does, scheduling is both simple and safe.