Actor Registry

[fulmicoton]

No description provided.

[boraarslan]

Looks great; I have two questions though.

1. Why are we using std::sync::RwLock instead of tokio's RwLock? Is there any particular reason?
2. Unwrapping a poisoned lock would result in a crash. Is this what we want, or do we have a recovery logic?

[fulmicoton]

Looks great; I have two questions though.

1. Why are we using std::sync::RwLock instead of tokio's RwLock? Is there any particular reason?
2. Unwrapping a poisoned lock would result in a crash. Is this what we want, or do we have a recovery logic?

Two great questions...

I'll start by 2.
Absolutely... In tantivy and quickwit, we try to make that kind of lock usage as trivial as possible.
This means: ideally, keeping your lock guard in its simple scope (not returning it, etc).
Ideally only execute trivial non-panicking code while the lock is held. Often this means we take the lock, clone the value and unlock. This is not great from a performance standpoint but this is much easier to read proof.
It is tempting to just use a magical implementation that cannot poison but the problem is not really solved is it?
If your tokio task panic while you where writing your object you might have left your object in an inconsistent state!
Panicking on the next lock acquisition is actually better than letting readers seeing (and possibly propagating/persisting etc) that inconsistent state.

1. The async Mutex is required if you have the lock accross an async.
   https://tokio.rs/tokio/tutorial/shared-state#on-using-stdsyncmutex

Outside of this, if something on which there are no contention like it is the case here, using sync::Mutex is fine, and actually more efficient.
By using a std::sync::Mutex I'm expressing that this is supposed to be a trivial case, and the reader should assume:

• a small scope
• only simple computation done (no IO for instance)

[fulmicoton]

As discussed offline with @guilload , we might want a registry for service like actors that are singleton (in the Universe).
Merging this and explorring this in a different PR.