Hacker News Reader

Comment by sltkr | Hacker News Reader

> ... you are going to get starvation as async does not have a fairness mechanism - timesharing is co-operative and based on FIFO in all the implementations I've seen.

If it's FIFO based, why would you get starvation?

View on HN

FIFO systems can have starvation when dealing with time bound things like web requests - slow request handlers can cause other (waiting) requests to timeout.

In a thread-per-request or process-per-request model where you run say 4 * cpu workers the operating system scheduler is able to interrupt stuff that's hogging the CPU but that isn't the case in a typical 1 * cpu worker async model.

When there's little cpu load this is not a real threat but when there is material load you can easily run into problems.

I see; it sounds like latency would become very unpredictable under that model. I can imagine that's a serious problem in practice, but it's not typically what's meant by starvation.

https://en.wikipedia.org/wiki/Starvation_(computer_science)

"Task does not receive resources to advance within the required time interval" is exactly starvation. A "task" here is responding to a request. The required time interval is the timeout.

ctrl+f'd "time interval", zero matches. The first linked source in Wikipedia, "Modern operating systems" even says a FIFO prevents starvation, "Starvation can be avoided by using a first-come, first-serve, resource allocation policy. In due course of time, any given process will eventually become the oldest and thus get the needed resource"

"Starvation" is being denied the necessary resource indefinitely. What you describe is "soft real-time failure".

I think these are equivalent when applicable, because starving a task long enough of a resource for either the resource to expire or the task's deadline to expire has the same effect as starving the task of the resource indefinitely: task fails to progress.

That's called "firm real-time failure". Again, the standard definitions of starvation/liveness only use "eventually" and "never" without mentioning actual physical time IIRC, and the real-time systems use a whole another bunch of concepts to deal with actual, physical time.

And it doesn't really fail to progress if it's cancelled on deadline expiration, it progresses to a non-successful completion. If it instead hanged indefinitely, yes, that'd be a problem.

Because any function can use as much time as it wants before returning. Event loops process events by calling functions which must return in order to allow the loop to make progress. Complex handlers will stall the loop and increase latency.

The recent innovations in asynchronous programming involve ways to signal to the programming language that the current task is blocked, thereby allowing the underlying loop to move on to the next event. While this improves the efficiency of the asynchronous processing system, programmers still need to use these features correctly just like coroutines.

What would the CPU-heavy code await on?

Reply on news.ycombinator.com