Multiple Io implimentations or overiding an implimentation

Explain
, ,
1

Hello everyone, I know that as I have read through quite a few posts and it has been brought up I wanted to know if there was any concrete clarification for several questions I have with IO.

  1. Will it be possible to use multiple IO implementations within the same program as long as you don’t swap out which implementation you may call something like cancel with IE if a func is create with Threaded Io, you cannot use Iouring’s implementation to call cancel on it.

  2. Given a particular context where Iouring maybe the Io implementation that we have specified, but a type can be accelerated only with Threaded but not Iouring, is there a way to detect the implementation and, if you can can you for the lifetime of that struct create your own Io implementation.

  3. If lets say you can only ever have 1 Io implementation, threaded, Iouring, threaded + iouring. Why is it we use function pointers and not a concrete type that directly call the functions and not introduce the indirection.

  4. I’m assuming it will be possible to create an Io that is threaded + iouring, but that has to be done at the implementation of the interface level. IE I cannot spawn a thread with threaded Io, and then in that thread create another Io interface that is iouring?

  5. Not so much as a question, but a request of the zig team. As someone who has been playing with Io sense day 1, I would greatly appreciate some insanely robust documentation, including some clear examples of common patterns IE block on list of tasks ignoring results, exiting early when a member of that list fails, good cancellation patterns etc. I really like the IO interface, but I feel like there needs to be a lot of very concrete examples, given that it’s rather novel in comparison to most if not all other async implementations.

1 Like
2
  1. yes, just like with the other versions of runtime polymorphism, std.mem.Allocator, std.Io.Reader and std.Io.Writer, std.Io is designed partially with this use case in mind.
  2. I don’t think so, and breaking the abstraction in this way sounds like ultimately a bad idea, since it, e.g. is pretty akin to recoloring your functions
  3. you actually are so close here to understanding why your “if let’s say” hypothesis is wrong
  4. this sounds not correct. i don’t know why you think that a program should have to have only one Io instance
  5. obviously this will come. i’m sure you can appreciate that providing documentation for something which is still pretty well in-flux can feel like tilting at windmills, and i’m sure the zig core team appreciates your patience and contributions on this front.
1 Like
3

Even after knowing you can have multiple Io instances, that doesn’t exclude a “concrete type”. It’s simply that a runtime interface: reduces duplicate code generation, provides a better dx on both reading docs/source and with current tooling (zls), and is just easier to reason about both using and writing an Io.

“Concrete type” in quotes as a runtime interface, is a concrete type, but Ik what you meant.

1 Like
4

You can mix and match different Io implementations in the same codebase

I did an experiment earlier with a web server app, using Io.Kqueue for concurrent handlers using fibers, and using an Io.Threaded instance for reading the request and writing the response (because the full network vtable isn’t finished yet with Evented)

It did work ok, and posted very excellent latency numbers on a heavy benchmark. Not saying it’s a good idea, but it does work.

4 Likes