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

David Anderson david at wordshell.net
Fri Sep 20 13:52:43 UTC 2013


Dion Hulse (dd32) wrote:

> The loopback request doesn't really cause any benefit due to delays or
> anything, the only benefit is that in doing so, it's locking the cron
> request for the DURATION of the cronjob through the random url value, where
> as when you call wp-cron.php directly, you're only locking it for
> WP_CRON_LOCK_TIMEOUT seconds.
I've read through the code a lot to try to understand this, but I 
don't... can you give me a clue?

1) "random url value" - where is this? I can't see any random element 
being added in the code, or in my web logs. I just see:

POST /wp-cron.php?doing_wp_cron=(microtime)

2) I also don't see how locking "for the DURATION of the cronjob" is 
happening. The lock is applied via the transient 'doing_cron'; but I see 
nothing in wp-includes/cron.php that is stopping that transient being 
over-written once WP_CRON_LOCK_TIMEOUT seconds have passed, and nothing 
that continuously updates it whilst the cron job progresses. I see these 
lines of code, in which the comment seems to say that this is where it 
is done:

     // don't run if another process is currently running it or more 
than once every 60 sec.
     if ( $lock + WP_CRON_LOCK_TIMEOUT > $gmt_time )
         return;

The comment says "don't run if another process is currently running" - 
but I don't see the connection between the comment and the code; the 
code only seems to do "don't run if ... more than once every 60 
(WP_CRON_LOCK_TIMEOUT) sec".

What am I missing?

David

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



More information about the wp-hackers mailing list