Use execution time timers instead of the batch size setting

Only for my interest - could you explain me why max_execution_time is not a reliable variable?

This code make sure that a module B stops processing after half max exec time is reached... if module A runs longer than the half exec time - above B cron cannot execute as half of the max exec time has already been reached... B needs to run it's cron tasks the next time cron have more time...

I do not expect that a site having 10,000,000 nodes have a sysadmin who is such stupid not having an PHP max exec limit... and the default PHP value is 60 seconds that is often overridden by core/modules to 240 seconds. Cron tasks override to 240s if ini_set() is not blocked by php config. There are a few places in core where max_execution_time is set to 240s... you could also set an more appropriate setting if 240s shouldn't be enough for xmlsitemap.

Aside - I do not expect that core works well with sites having 10.000.000 nodes and high traffic... we see how slow it often works in d.o with only ~500.000 nodes... But this is OT here and it couldn't be wrong to develop for hypothetically 10.000.000 node sites :-)

With the above code we do not need to ask the user again to make an assumption that may often fails and cause other issues. The current setting is hard-wired over all cron tasks of a day and sometimes cron have to do more work and sometimes less. If there is more other work to do - it might fail.

Take a look to #386612: Prevent possible cron failures caused by too many link checks how difficult it could be to calculate an appropriate value and how difficult it is to use a good configuration that wouldn't delay a complete link check to finish in weeks (linkchecker module) and what users do if you give them such a setting (cron overload). A "save" value that should make cron never time out is 10 (for linkchecker), but with the new approach the module can check ~120 links (or more) without any cron failure. If I transfer this to xmlsitemap the module may be able to add/rebuild only ~10 links safely per cron run, but with the timer check you might be able to add 1000 (guessing).

Users don't need to setup a max time execution with the above approach - it's already defined in the php.ini

PS: It was planed to add job_queue module to D7 core... if this will happen this logic goes into core.

Dave, how can you say that it's possible to add - let's say 1000 links? If linkchecker and other modules consume all the available cron processing time the job fails... - if no other module have cron tasks it will work... but only in such a situation. If you think about high performance module such a solution need to be implemented.

Thank you very much for the D7 link - I wasn't aware about this commit.

Only to note - the patch in http://drupal.org/node/410656 seems to be the followup and have this code:

+/**
+ * Worker function for job scheduler.
+ */
+function system_scheduler_work() {
+  // Work for 50 % available max execution time, but not longer than max
+  // execution time itself. Assume a safety buffer of 30 seconds.
+  // @todo: this could be made adjustable.
+  $max_execution_time = ini_get('max_execution_time') - 30;
+  $time_out = time() + $max_execution_time / 2;
+  $time_out = $time_out > REQUEST_TIME + $max_execution_time ? REQUEST_TIME + $max_execution_time : $time_out;

Therefore you need job_queue or implement your own solution that works like above. Don't close cases you do not understand, please. Dave said "postponed".