Skip to content

Comment on Concurrency in Swift: One possible approach

Comments

Software interrupts is the right answer to concurrency nonsensical hype. Sometimes old is gold.

Wrapping specialized interrupt handlers into some higher lebel API, such as AIO, is the right way.

Async/await is a mess. Concurrency cannot be generalized to cover all the possible cases. It must have specialization.

Engineers of old times who created the early classic OSes were bright people, contrary to current hipsters.

Once popularized, flawed abstractions and apis such as pthreads would stick (only idiots would accept shared stack and signals).

Look at how an OS implements concurrency and wrap it into higher level API. That's it.

Your comment is rude and factually very wrong. The new languages we discuss are definitely not written by "current hipsters", whatever you meant with that.

How does the OS implement concurrency, which is a userspace problem?

Software interrupts alone are not enough, you still need some language support to it. I am not sure you really know what concurrency even means...

concurrency, which is a userspace problem

This is another gross misconception, like an attention to manage resources from the userspace, the way JVMs or Node are trying to do by poorly reimplementing OS subsystems.

Concurrency primitives must be implemented by an OS - it will eliminate all the userspace problems - no busy-waiting, no polling, no waking up for every descriptor, etc.

Ignoring an underlying OS instead of having thin wrappers, like Plan9 from userspace does, is exactly what is called ignorance (lack of awareness of a better way).

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.