This bug has been haunting me for a week. This question is previously posted in Stackoverflow. However, no one actually read it and therefore I came here with some developments I discovered these days.
So I've been trying to write a Lock over a vector to provided async read/write for multiple threads. The idea is to use
tokio::run and then
tokio::spawn a bunch of async threads that tries to lock a
futures_locks::RwLock<Vec<Seed>> and then
get(k: SeedId) or
push(s: Seed). The sequence and behavior of these threads are hard-coded in main function.
If the index is not present yet, the thread will return
Async::NotReady and push this task to parked list.
If a data is pushed, it checks if there are any thread in the parked list that wants this data and
However, the program may panic when a reader/writer attempts to drop the lock. According to
rwlock.rs:457/470/475, when a thread is dropping the lock, it will
mpsc::Sender::send(()) to the next one in line to notify them that the lock is ready to use. However, in seed-store,
send(()) failed because the receiver is dropped. This caused all the following threads to panic as the lock is then poisoned.
Something that I have tried:
Remove notify feature
Done in a new branch. Now when the Seed is not available yet, the thread will return a dummy Seed. But the problem is still there, so it's not this feature's problem.
Tried. Won't work. Panics on
send(()), almost the same with
Tried. Won't work. Some threads still hangs(without panic).
The above two changes combined made me believe that there are some code logic bugs that I can't tell.
(Partially) worked. File::create will fail and no file will be dumped. Also,
current_thread won't use a thread pool(therefore it doesn't have a poison problem), this hurts performance.
I have posted these code here. Sorry I can't post a link to the playground so you can run it directly, I can't use futures_lock in the playground.