[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