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

[David Anderson]

> Why are you hitting the wp-cron.php file directly? WordPress doesn't
> do that normally.
>
> WordPress normally sets the doing_wp_cron transient with the current
> time(), then calls wp-cron.php?doing_wp_cron=time. This is a locking
> mechanism to prevent the subsequent calls after that from running.
>
> This is not *perfect*, but it is pretty good and prevents most of the
> problem you're describing. If you're calling wp-cron.php directly,
> you're bypassing this mechanism, and the delay you've added to the
> database will cause the locking mechanism to take longer, causing the
> race issues.
Hi Otto,

Thanks... I was aware of that; the reason I was hitting wp-cron.php 
directly in the tests I mentioned in my early mail was for two reasons: 
1) On my reading of the code, wp-cron.php tries to apply the same lock 
(the section beginning with the comment "// Use global $doing_wp_cron 
lock otherwise use the GET lock. If no lock, trying grabbing a new 
lock."). 2) In my tests, going indirectly (hitting the site's home page) 
had the same effect - i.e. the action would still consistently run 
multiple times due to raciness. It was just slightly less racy, but I 
surmised that that was due to a side-effect of timing due to the extra 
HTTP round-trip, rather than due to any extra locking taking place 
(which I surmised because of 1) - I can't see any extra locking take 
place - only a difference as to the timing of *when* the locking takes 
place).

David

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