Async-ify the API

[cdmistman]

Are there any plans to provide async compatibility? I think this could be useful for a few things, even opening up the ability for a possible (clean) actor system or something similar

[KillingSpark]

I dont really see this happening in the near future. To transfer filedescriptors, a call to sendmsg/rcvmsg is necessary. I am not aware of an async version of these functions as of yet.

[cdmistman]

As there'd need to be duplicate code anyways, maybe it would make sense to require using an fd for the async connections?

[KillingSpark]

I am not sure if I understand what you mean. Rustbus does already operate on the raw fds. It uses the nix crate to call send/recvmsg on the raw fd it gets from the stdlibs UnixStream. The problem is, that those two functions would have to be async, for the API to become async right?

[cmaves]

It is definitely possible to implement this as async without the send/recvmsg being async. All syscalls are "synchronous". Async libraries like async-std and tokio workaround this in a few different ways by respectively either using a special thread-pool to handle blocking calls, or by using non-blocking calls combined with some kind of event-poller (a wrapper around epoll/kqueue/whatever-windows-uses), to register calls as ready.

If async is to be implemented it may be best for it just to be its own crate or at the very least behind a feature flag, because it would require a pretty significant reworking of the Conn and RpcConn codebase. The unmarhaling/marshaling code as well as some of the message structs would be shared and would probably need to be moved into a separate crate like rustbus-core, that the primary crate and async would share and reexport from.

I would be interested in implementing this because I have would like to make my own crates async, but there is a lot of other work going on by @KillingSpark that probably needs to settle before this could begin.

[KillingSpark]

Yes I think it would waste a lot of effort to try this now while the internals are still in this much change. I am myself not really familiar with the whole async stuff to be honest, so having that as a separate crate is likely a good idea.

[cmaves]

I've created an async API in a crate built on top of this crate. It can be found here. It is unreleased, but it almost ready to go. It signal handling hasn't been completely flushed out but otherwise it is good to go.