getsentry / barbados Goto Github PK

There is in general two approaches to workers:

1. start worker tasks ahead of time
2. start worker tasks on demand

We currently use 1. but there should be an experiment with approach 2. in the commit history as well.

There is also a question of how to properly make this panic-safe, meaning that panics from submitted tasks do not interfere with queue operations. For some reason I was fighting with the compiler over being able to use futures_util::future::CatchUnwind. Maybe that was just me not knowing how to properly use that, but the implementation right now is not panic-safe.
A panic in a task will essentially kill that whole worker, making it unavailable from then on.

• Spawning one tokio task per queued task would solve that halfway, although keeping track of the number of running tasks still needs to be taken care of
• Having always-running worker tasks is nice because it avoids repeated Arc-ing all the time, but might have overhead imposed by tokio.
• On the other hand, spawning tasks on demand requires Arc-ing a bunch of stuff each time, and also imposes overhead from tokio for spawning tasks.
• Spawning on demand can also be done either with a dedicated always running scheduler, or truely on-demand in the enqueue method, and having already started tasks keep servicing the queue.
• ^ though the above would also require the workers to be panic-safe.