Hacker News new | ask | show | jobs
by masklinn 1833 days ago
I’m guessing they mean that programs which did not want to block on syscalls and had to deploy workarounds can now just… do async syscalls.
1 comments

Which is every program that wants to be fast, on modern computers. So...
Nonsense.

Let's say your program wants to list a directory, if it has nothing to do during that time then there is no point to using an asynchronous model, that only adds costs and complexity.

Let's say your program wants to list a directory and sort by mtime, or size. You need to stat all those files, which means reading a bunch of inodes. And your directory is on flash, so you'll definitely want to pipeline all those operations.

How do you do that without an async API? Thread pool and synchronous syscalls? That's not simpler.

At no point did I say that these APIs were not useful? I’m literally the person who explained what kind of uses would be simplified by async syscalls.

And you can keep your strawman to yourself. I objected to the statement that it would make all programs faster / simpler, the argument that it would make some simpler or faster is not something I ever argued against.

> I objected to the statement that it would make all programs faster / simpler

And I pointed out that even the simplest example you could come up with can in fact be made faster (than implementing sequentially) or simpler (than implementing with threads, which require synchronization) with an async API. So I don't see the straw man.

Pretty much anything that needs to interact with the kernel can benefit from this.

> And I pointed out that even the simplest example you could come up with can in fact be made faster (than implementing sequentially) or simpler (than implementing with threads, which require synchronization) with an async API.

No, you pointed out that a different example could be made faster (and almost certainly at the cost of simplicity, the mention of which you carefully avoided).

> So I don't see the straw man.

That doesn't surprise me.

True. But as soon as your program wants to list two directories and knows both names ahead of time, you have an opportunity to fire off both operations for the kernel to work on simultaneously.

And even if your program doesn't have any opportunity for doing IO in parallel, being able to chain a sequence of IO operations together and issue them with at most one syscall may still get you improved latency.

Yes and even clustering often-used-together syscalls... An interesting 2010 thesis https://os.itec.kit.edu/deutsch/2211.php and https://www2.cs.arizona.edu/~debray/Publications/multi-call.... for something called 'multi-calls'

Interesting times.