Closed progval closed 1 year ago
Spawning a task on each event to send implicitly used tokio as an unbounded queue that doesn't actually preserve order.
This could cause issues, such as ConnectionData being sent after the first message, which violates assumptions down the line.
This replaces #28 but avoids re-creating the original deadlock by creating a new task with its own loop.
Spawning a task on each event to send implicitly used tokio as an unbounded queue that doesn't actually preserve order.
This could cause issues, such as ConnectionData being sent after the first message, which violates assumptions down the line.
This replaces #28 but avoids re-creating the original deadlock by creating a new task with its own loop.