At least since 4.6 and probably earlier too, cron tasks have been (as I see them) an unclassified amount of tasks handled by module on all cron runs, requiring each module to take uncoordinated steps on its own to manage its own scheduling, with the net result that cron tasks have to fire all existing hook_cron implementations, potentially to memory exhaustion problems in many hosting situations (see the number of issues around this, notably regarding search).
One way to work around this would be to enable cron-based scheduling instead of module-based scheduling, and/or allow cron to be called to invoke specific cron-ed tasks instead of the whole lot, much like the original UNIX cron uses a crontab instead of relying on every cron job to know when it must be scheduled.
- one instance of scheduling code instead of many incompatible ones
- ... which can justifiy the work going into a nice scheduling UI
- ...without preventing modules from doing their scheduling themselves
- ...and can still work with the existing hook_cron specification
- ability to reduce the memory/cpu requirements on cron runs. For instance, long-running tasks like search indexing can be run on their own instead of along with the othet tasks, reducing breakage probability
- ability to minimize the impact of choking tasks, like aggregator updates failing to obtain the upstream source, since these would be performed on their own runs instead of along other tasks
- probably still compatible with poormanscron
- potential compatibility loss for some situations (which ones ?)
- some form of reentrancy would have to be considered: unproperly scheduled cron tasks would be more susceptible than now to being invoked without the previous run being finished. A solution would probably to handle the runs within cron as some form of critical section, now allowing a scheduled subtask to be started if the previous run has not returned (possibly with a failure situation)
What do you think of it ?