any workaround to allow registering to different Poll?

[jkarneges]

The docs mention this limitation: "A handle can be passed back to register after it has been deregistered; however, it must be passed back to the same Poll instance, otherwise the behavior is unspecified."

I wonder if it's possible to work around this, for example by using into_raw_fd / from_raw_fd to throw away any mio-specific state. Or is this an unavoidable OS-level limitation even on unix?

Rationale: we have an application with a Poll instance per-thread, and we are looking at implementing a global connection pool.

[Thomasdezeeuw]

The docs mention this limitation: "A handle can be passed back to register after it has been deregistered; however, it must be passed back to the same Poll instance, otherwise the behavior is unspecified."

I wonder if it's possible to work around this, for example by using into_raw_fd / from_raw_fd to throw away any mio-specific state. Or is this an unavoidable OS-level limitation even on unix?

Mio on Unix doesn't hold any state, just the file descriptor. This limitation is OS based, nothing Mio can do about it. The only work around is close the fd and reopen it.

Rationale: we have an application with a Poll instance per-thread, and we are looking at implementing a global connection pool.

I've personally started a central/shared Poll instance for this driven by a thread that just does that (and relaying process signals). It work pretty well, but you'll have slightly more overhead in thread scheduling (due to the another thread need to run).

[jkarneges]

Is it fair to say that moving registrations is allowed by mio if the developer is careful to only do it on platforms that support it? For example, in sections with #[cfg(target_os = "linux")]. Or might mio change in the future and break this ability?

[jkarneges]

Even better would be to add a const to the lib, say mio::CAN_MOVE_REGISTRATIONS. That way, apps could be written more portably and have more assurance. Would you accept such a PR?

[Thomasdezeeuw]

I'm not sure. I don't think it's the right direction for Mio to add should a feature. Mio try to make non-blocking I/O cross platform, while exposing the OS specific details where it can. But this would be such a footgun that I'm not willing to maintain it.

I think the best way is to use into_raw_fd / from_raw_fd, but this will not be supported by Mio.

[Thomasdezeeuw]

@jkarneges anything we can do here still or can this be closed?

[jkarneges]

Thanks for checking @Thomasdezeeuw.

This issue is tricky from a version compatibility standpoint. Currently, I plan to check the platform in my app to decide whether registering on a different Poll is allowed or not. However this would rely on mio's "unspecified behavior" remaining semver consistent.

I suspect mio probably won't break current reregistration behavior without a major version bump, due to your or other contributors' awareness of the matter. That is, probably mio would not add extra state to socket objects or change backends in a way that would break projects like mine. So probably the platform check will be sufficient, even if it feels a little unsteady. Does this seem like a reasonable expectation of mio?

Of course, keeping a flag in mio would be best (then you can break the behavior whenever you want by just flipping it to false for any platform), but I can understand if you don't want to maintain such a thing.

[Thomasdezeeuw]

This issue is tricky from a version compatibility standpoint. Currently, I plan to check the platform in my app to decide whether registering on a different Poll is allowed or not. However this would rely on mio's "unspecified behavior" remaining semver consistent.

Do mean getting the raw fd from mio::Poll and then e.g. on Linux assume it works?

I suspect mio probably won't break current reregistration behavior without a major version bump, due to your or other contributors' awareness of the matter. That is, probably mio would not add extra state to socket objects or change backends in a way that would break projects like mine. So probably the platform check will be sufficient, even if it feels a little unsteady. Does this seem like a reasonable expectation of mio?

I can say that Mio won't change away from epoll/kqueue in the v1.x series (once that is released). Any change to e.g. something io_uring based will become a v2.

Of course, keeping a flag in mio would be best (then you can break the behavior whenever you want by just flipping it to false for any platform), but I can understand if you don't want to maintain such a thing.

I think it would encourage non-cross-platform behaviour which has so many tricky things to them that I'm not sure if we should even attempt to maintain something like that. So, if the mio::Poll -> epoll fd method works for you I rather not add anything to Mio.

[jkarneges]

Do mean getting the raw fd from mio::Poll and then e.g. on Linux assume it works?

Exactly.

I can say that Mio won't change away from epoll/kqueue in the v1.x series (once that is released). Any change to e.g. something io_uring based will become a v2.

Thanks, this assurance is enough for me. Will close.