feat(services/monoiofs): monoio wrapper

[NKID00]

Part of #4552.

Since monoio runtime can't cooperate with tokio runtime on the same thread, this PR introduces a wrapper in monoiofs that wraps monoio runtime in a thread pool and provides a method that may be called in context of other runtimes to dispatch futures to the thread pool and execute it in context of monoio.

This is similar to the implementation of compfs, however since monoio doesn't provide a crate like compio-dispatcher to do these, I've implemented a minimal usable dispatcher here. This dispatcher implementation sends futures to threads at random (same as compio-dispatcher) without scheduling or load balancing, but it should serve for implementing rest of the service on top of it and we can improve its performance later if necessary.

[Xuanwo]

Since monoio runtime can't cooperate with tokio runtime on the same thread, this PR introduces a wrapper in monoiofs that wraps monoio runtime in a thread pool and provides a method that may be called in context of other runtimes to dispatch futures to the thread pool and execute it in context of monoio.

This is similar to the implementation of compfs, however since monoio doesn't provide a crate like compio-dispatcher to do these, I've implemented a minimal usable dispatcher here. This dispatcher implementation sends futures to threads at random (same as compio-dispatcher) without scheduling or load balancing, but it should serve for implementing rest of the service on top of it and we can improve its performance later if necessary.

That sounds great. I recall @ihciah mentioning that they've done some work internally to make monoio compatible with the tokio runtime. Do you think this feature should be integrated into the upstream monoio?

[NKID00]

That sounds great. I recall ihciah mentioning that they've done some work internally to make monoio compatible with the tokio runtime.

Yes, there is already a compatibility layer crate monoio-compat. But AFAIK, this crate focuses only on api-level compatibility with tokio. It mainly facilitates porting existing tokio-based code (especially network related) to monoio and still requires user to run the code in context of monoio. However the goal of monoiofs is to operate even in context of other runtime such as tokio, and we don't need to port existing code either.

Do you think this feature should be integrated into the upstream monoio?

My code here only focuses on our use case inside monoiofs. There are a few issue comments in monoio requesting similar feature but most of them concern other scenarios. Maybe we can later generalize it and contribute that to monoio.

[Xuanwo]

Hi, @NKID00, thanks for your update. This PR is mostly ready to merge, can you help resolving the conflicts?

[NKID00]

Hi, NKID00, thanks for your update. This PR is mostly ready to merge, can you help resolving the conflicts?

Sure.

[Xuanwo]

Thanks, let's move!