[kragen]

Yes, I agree. Something similar is why I don't think it's accurate to describe this article as being about actors: it's not about schedulers, but it's about asynchronous I/O, which is equally well not the same thing as actors, though scheduling and asynchronous I/O both have very interesting relationships with actors, which the article unfortunately does not go beyond vaguely gesturing at.

[mpweiher]

Sorry, but you are first changing "what the article is about" to something that the article is not, in fact, about, and then criticizing this thing that you just made up.

Not helpful.

[kragen]

I don't understand what you're saying; could you clarify which three things you are referring to?

I found your other comment above, the one mentioning Smalltalk, very interesting, and will reply to it later after thinking more about it.

[mpweiher]

I will do my best.

1. You:

> I don't think it's accurate to describe this article as being about actors

So the article says it is about actors. It says it is about messaging, it certainly is about asynchronous messaging, and you even agree that io_uring is an asynchronous message queue.

In what way is the article not about a connection between actors and io_uring?

This is what I mean when I write that you are changing what the article is about. It is about this: asynchronous messaging/actors.

It may not go into a lot of depth about that connection, but it clearly is about it. And it may be wrong to focus on this. It may be wrong in how it describes it. But you cannot claim that it is about something else.

2. You:

> it's not about schedulers

Yes. And? Why does an article showing the connection between a general concept of asynchronous messaging (actors) and a specific instance of asynchronous messaging (io_uring) have to be "about" schedulers?

Please don't answer, it is rhetorical question.

3. You:

> but it's about asynchronous I/O

This is where you actually do the change. No: it is not about asynchronous I/O (in general). It is about an asynchronous messaging interface to I/O. Not the same thing. At all.

Once again, maybe you think it should be about this topic instead. And maybe you are even right that it should be about this (I don't think that's the case). But even if you were right that it should be about this other topic, you are not free to claim that it is about this other topic, when it clearly is not.

4. You:

> Asynchronous I/O completion notification was a huge innovation, ...

> But don't try to sell asynchronous I/O as a "game-changing" paradigm shift...

That's where you criticize the article for the thing you made up that it should be about, but is not. The article is not even about asynchronous I/O in general at all, never mind trying to sell asynchronous I/O as anything. It is talking about messaging, the fact that you can regard io_uring_sqe as a message and the submission and completion queues as message queues. Yielding something that's roughly equivalent to (some version of) the Actor model.