Open Johni0702 opened 5 years ago
I believe that whatever is going wrong, is happening in the .wait()
function of 0.1 Future
s, and not necessarily on our end. I can't be quite sure, but I was planning to port ratelimit_futures forward to the std futures anyway; maybe that'll fix this bug too.
This was indeed a bug with futures 0.1. I've started a new project since then, governor
, which builds on std futures. I likely will abandon this project and ratelimit_meter
in favor of governor, so this issue will remain open. I'd encourage you to upgrade! The interface is really similar, and works better!
Seems like the
multiple
test can end up in a dead lock. More or less reliably reproducible by just running that test until it locks up (usually within milliseconds, roughly 10% chance). I haven't had a closer look at it.gdb -p 5315 -ex 't a * bt' --batch
``` [New LWP 5316] [New LWP 5320] [New LWP 5336] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007494babba72c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts of file /home/user/rust/ratelimit_futures/target/debug/deps/ratelimit-d60df3ee53b9e5ed. Use `info auto-load python-scripts [REGEXP]' to list them. Thread 1 (Thread 0x7494ba842980 (LWP 5315)): #0 0x00007494babba72c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000057e239ac05b3 in wait () at src/libstd/sys/unix/condvar.rs:69 #2 wait () at src/libstd/sys_common/condvar.rs:41 #3 wait<()> () at src/libstd/sync/condvar.rs:204 #4 park () at src/libstd/thread/mod.rs:910 #5 0x000057e239ac6ba2 in wait () at src/libstd/sync/mpsc/blocking.rs:71 #6 0x000057e239a3b485 in recv<(test::TestDesc, test::TestResult, alloc::vec::Vec