What’ the locking issue you see? The C++ standard library makes some of the common errors harder to make, at least.
edit: this is how wait_for / wait_until work:
while (!pred()) {
if (wait_until(lock, timeout_time) == std::cv_status::timeout) {
return pred();
}
}
return true;
so if we see _buf_count == 0 but the increment in the other thread wins the race with us acquiring the lock, wait_until just returns immediately (because the predicate is true on entry) without ever waiting.
(that said, touching _buf_count with no lock is a bit hairy)
Yeah the predicate is checked on entering the wait, so it’s not an issue.
Don’t think it’s an issue as this thread is the only one decrementing that variable.
And seeing 0 instead of >0 is not an issue for the logic, while it should never see >0 if it’s actually 0.
So no i don’t see anything, i suppose it’s more likely the rx_callback is not firing for some build or other reason.
After getting failures of dump978-fa, I did do a reimage & fresh install, both in VM and on OrangePiPC, and got same result.
In addition, as dump1090 was working OK, I swapped device serial numbers in /etc/default/dump1090-mutability and /etc/default/dump978-fa, and rebooted the machine/pi. The dump1090 continued working OK and dump978-fa again failed. This shows that the problem is not in the dongle, or usb port or the machine.
In 2nd Debian-10 (reimage), I installed dump1090-mutability EB_VERSION by sudo apt install dump1090-mutability
In 3rd (current) Debian-10 install, I installed dump1090-mutability ver 1.15~dev.
Only in current install, I have installed librtlsdr0 as dependency of dump1090-mutability ver 1.15~dev. Has librtlsdr0 stopped the failure of dump978-fa?
I will tomorrow make 4th reimage of Debian 10, and this time wont install dump1090-mutability ver 1.15~dev and librtlsdr0. Instead will built & install dump1090-fa which does not require librtlsdr0, and see what happens.
$ cd piaware_builder
$ git reset --hard origin/master
HEAD is now at 8cdcb9e Release 3.8.0
After that I deleted the folders created by the installation git commands for dump1080-fa and piaware.
Then I have run only the portion after git clone procedures to download the new files.
The Bionic builds the FreezeCx 6.0 so the “patch” of 5.1.1 is not required anymore.
I had to change in the build instructions the 3.7.2 with 3.8.0 and everything worked well, I am feeding now from the 3.8.0 (instead of the branch 3.8.0 dev) and all seems to be OK.
That’s not really a failure, it’s just not signed as you’re not Eric Tran.
But as you can usually trust yourself, the package not being signed is not an issue.
You can add --no-sign to the buildpackage command, that will remove the error.
But really it doesn’t matter.
