No way to implement external events due to blocking recv_event

[tuxmark5]

Right now the only way to poll events from a Connection is to use recv_event, which is a blocking operation. As a result, it's impossible right now to implement a bot that listens on external events and produces Discord commands based on those events.

To fix this, there should be either a non-blocking alternative to recv_event, or a Future/Stream interface for streaming the events.

[anna-is-cute]

recv_event being the only method in which to receive events also makes it incredibly difficult to implement a cleanly-stopping bot that uses Connection.

For example, to cleanly stop the main event loop, you have to create a new thread and move Connection inside. Inside the thread, recv_event will block and you use a channel to send events out of the thread, where the main event loop, using select!, can process events and also get a shutdown signal to cleanly break out of the main loop when necessary (Ctrl-C, supervisord, etc.).

This is fine, but when you need access to Connection, such as when you want your bot to connect to voice, it gets hairier. If you make an Arc<Mutex<Connection>>, you can almost make it work, but recv_event blocking indefinitely means that other threads waiting to get a lock on Connection must wait until another event is received and the Mutex becomes unlocked.

I'd love to see a different way to receive events that enables this flow to work.

[SpaceManiac]

Clean shutdowns triggered by external events are probably the thorniest situation caused by the current blocking recv_event structure.

There are a couple of ways to handle other event sources. If all you need is to trigger Discord API calls based on events from other sources, run them in their own thread and use an Arc<Discord> to share the Discord struct between them, allowing the other threads to make API calls. If you need other sources to know current state, pass around an Arc<RwLock<State>>. If you really want to have your own event loop be the main event loop, put Connection in a thread and feed the result of recv_event down an mpsc::channel forever, as discussed.

Connecting to voice based on an external event is another point of difficulty. I intend to analyze all this at some point and figure out what can be done. The main obstacle is building on top of the underlying websocket and TLS wrappers which aren't immediately amenable to non-blocking or asynchronous I/O. I also think tokio is too young and complicates both library and client code too thoroughly to be worth implementing just yet, though it has a very promising future.

[jD91mZM2]

If possible, the simplest solution could be to not take a mutable reference in recv_event. Sadly, I suspect an upstream repository has it that way?

[tinaun]

the latest websocket has a .set_nonblocking() method on streams and clients. because sslstreams cannot be split anymore (its unsafe), i was thinking about moving the entire client into the keepalive thread, handling all heartbeat and reconnecting logic there, and adding a second mpsc channel to send events back to the connection object, which could be read in both blocking and nonblocking ways from the connection object.

any thoughts?

i do agree that async would be nice, but its still pretty early and awkward right now, and i feel like its important to keep having sync libs too.

[jD91mZM2]

I think anything that actually makes this possible seems fantastic.

[SpaceManiac]

If you can make it work while keeping close to the current interface, I would happily accept that PR.

[domenicquirl]

Hi everyone! Has there been any progress on this since the issue was last updated? I've run into the same scenario as @ascclemens describes in their final paragraph regarding the blocking call to recv_event getting in the way of an audio thread that also needs the Connection.