[wp-hackers] Dealing with WP cron's raciness

[David Anderson]

Hi,

The WP cron system suffers from race conditions. Is this known by core 
developers, and how do they feel about it? i.e. Is it here to stay, or 
are there plans to improve it?

Easy way to reproduce (every time):

1) Load up the machine with your MySQL server on so that it's fully 
loaded (so that there's some latency - this is the crucial bit):
(e.g. run a few of these: while true; do wget -O - 
http://localhost/mydevwebsite; done )

2) Create a simple mu-plugin:

add_action('crontest', 'testing_crontest_da');
function testing_crontest_da() { error_log('cron test!'); }

3) Create a few processes that are continually calling wp-cron.php (two 
or more):
while true; do wget -O - http://localhost/mydevwebsite/wp-cron.php; done

4) Schedule a single cron event:

<?php require('wp-load.php'); wp_schedule_single_event(time()+5, 
'crontest'); ?>

The result will be that the 'listener' in 2) logs as many lines as you 
had tasks calling wp-cron.php in 3). i.e. the action gets called that 
many times.

This isn't a problem for scheduled tasks that are performing cleanup 
jobs (e.g. cache purges). But for something like a scheduled backup, 
it's annoying - you get two backups. For a task that sends out report 
emails, you get multiple reports. etc. Of course, each plugin that 
performs such tasks could write its own locking system... but these 
would be likely to each have their own ad hoc quirks. It'd be much 
better if WP's cron system was less racy.

Thoughts?

David

-- 
WordShell - WordPress fast from the CLI - www.wordshell.net