[jrgnsd]

There's a number of solutions, depending on your stack: at and cron are good OS level solutions. Sidekiq is great for Ruby.

I think the problem lies in that PHP wasn't designed to be a long running process, and for a scheduler you need something long running.

[contingencies]

Having done this (years ago), there are good reasons sometimes. At the time I was working on a relatively complex hotel reservation system with a distributed database and the need for batch execution of background processes (things like sending emails and digital fax from a queue).

The master interface to the database was a series of PHP functions since the data massaging that had to occur (to facilitate correct interaction in multiple human languages across disparate timezones versus user preferences and time of day, etc.) ruled out direct DB access from anywhere else, back-end processes included.

I think the end solution was something like 'every minute run PHP X from cron, which checks if there are jobs, if so successively spawn children to handle'. It was basic but it worked. Godawful pain with MySQL replication over lossy Chinese internet WAN ... never again.

[jrgnsd]

I inherited a similiar system. It was painful to say the least. I didn't realise how painful until I started using proper queueing systems and Sidekiq.

[contingencies]

Sidekiq doesn't really look that different to what we used.

Anyway, neither decent ruby unicode handling nor RoR nor sidekiq existed back then. I actually considered rewriting the whole system in ruby at one point, but the unicode support was still dodgy.