In cron.php, it sets PHP maximum execution time to 240 secs which is only 4 minutes. Since it invokes cron jobs that user-provided modules may have, we shouldn't have placed that hard-wired limit. It's possible that someone may need to perform long operations via PHP (the longest php script I ever executed took many hours to complete).
I suppose to make maximum execution time and maximum allowed memory utilisation settings configurable in settings.php, both of these settings can be changed on-the-fly while a script is running, so you would place a variable instead of a hardwired number in the relevant functions.
With these settings a script can run forever:
ini_set( 'memory_limit', -1 );
set_time_limit(0);
The configurable code would look like this:
ini_set( 'memory_limit', $a );
set_time_limit($b);
The user would specify $a and $b in their settings file(s). Drupal should be able to assume some default values for these variables if they aren't set. So there could be some is_set() test or something similar before their use.
Comments
Comment #1
nsk commentedThis discussion could also be more general about whether Drupal should have hardwired limits or not. I believe site operators know more about how many resources their scripts should use, so we shouldn't decide for them. Some limits are variables in the code but are limited by the Drupal's XHTML interface, for example a user cannot allow more than 30 nodes in the frontpage or taxonomies without hacking their settings file. I think both the code and the interface should allow the user to do whatever they want.
Comment #2
magico commentedMakes sense?
Comment #3
LAsan commentedAny thoughts about this?
Feature request go to cvs.
Comment #4
mdupontI guess the answer is no, since the issue is old and forgotten. Most wouldn't be happy to see Drupal change dynamically the memory limit...