| At Google we actually had 'prefer new' (ie a stack instead of a queue) for certain jobs, that were likely no longer useful after some time had passed; and where less and less useful the longer you waited until you started. One example was running certain ad auctions when rendering websites, or something like that. You don't want to delay serving the side, if the ads are delayed. So you have a certain wall clock time budget until the rest of the page is assembled to be sent to the user, and if you can fit your ad-serving in there, that's good. If you have more work than you can currently handle, then it makes sense to continue with the newest open request after you handled the previous request. The actual system was a lot more complicated, and combined a short, bounded queue on the inside with a large stack on the outside or something like that. Similar considerations can apply, when you are one of many competing market makers for some financial assets on an exchange. Basically, if you have a situation where serving quick is a lot more important than the distinction between late and very late (or even dropping the request). |