3 ms·
I am responding to the very last point about dropping a future and the resource usage. Let's assume a future that implements reading from a network socket. And
by bombela 3y ago
I am responding to the very last point about dropping a future and the resource usage.
Let's assume a future that implements reading from a network socket. And the file descriptor (fd) was already passed to epoll/select (I am ignoring io_uring).
After dropping the future, the socket is is still being considered by the kernel for reading. Eventually epoll will return, and the IO runtime (like tokio) will notice the stray fd and discard it. And can you even close the fd before it is out of epoll?
So until the fd is back to user land, it appears very similar to leaking resources. Even if only for a short time while the IO loop is completing an iteration.
- insanitybit 3y agoI'm not sure how an actor would solve that problem. You're describing the way a system call works, which is not relevant to how your userland asynchrony works. In either case you're always "leaking" (I'd say "holding") the resource while you wait for the kernel to give it back to you.
- bombela 3y agoIndeed I was merely describing how it behaves within the context of future + ioloop with tokio. I didn't take a stance on future vs actor. In Rust my instinct tells me the difference between actor and future is negligible. Because it compiles down to almost the same thing. But I wouldn't bet my life on it. Note that my understanding of what an actor is might be wrong. I assume an actor is a sort of thread with a main ioloop receiving and sending messages. Which is basically what a tokio ioloop thread is. Atop of which the futures give you an abstractions to compose IO functions more easily.
- insanitybit 3y agoYep, that's basically an actor.