The built in cron runner just runs at the end of the request, which is horrible. Seefor amusing things you can run into now due to this.
It was originally put in running from a 1px gif, but this was reverted later since that 1px gif meant a full Drupal bootstrap every time it was requested (including when that 1px gif was served from a cached page, so you'd hit Drupal even if you were serving pages from varnish).
However there's new tricks now, so we don't need to do either. If we have this, then it'll also be most of the necessary infrastructure for.
This depends onsince one of the criteria for finding a new http client is that it can handle non-blocking HTTP requests. So marking postponed, but leaving at major since this is a nasty gotcha on sites that don't want it, and crappy performance for those users who are unlucky enough to be the ones to trigger the cron run.
We could also fire each cron hook in its own separate PHP runner to keep memory usage down and prevent an error in one cron job killing the others, doesn't necessarily need to be done here though.
PASSED: [[SimpleTest]]: [MySQL] 50,741 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cron-async-request-1599622-13.patch. Unable to apply patch. See the log in the details link for more information. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cron-async-request-1599622-8.patch. Unable to apply patch. See the log in the details link for more information. View
PASSED: [[SimpleTest]]: [MySQL] 49,400 pass(es). View