Frank Brickle wrote:
Robert McGwier wrote:
There are subtle race conditions that might occur but they are minor
irritants compared to the stupidity of what we were doing.
In particular you'd want to make sure any values that can be read in
the callback are set atomically in the client code. That includes
flags that trigger resets in the callback.
Bob's recounting of our joint mental blunder is a little
oversimplified. My operating principle was that, once the callback is
started, the ring buffers are *never* reset. This is correct in
principle but unworkable in practice. Unfortunately the resets were
kind of wedged into the code and not properly thought out, by me mostly.
Actually, this exact same error was in and DID occur in the dead bug
version naked buffer exchange code . On PTT I memset the buffer to zero
to stop transmit noise from entering receiver code and vice versa. And
of course, the callback can and did overwrite this operation. There is
enough ooopsie to go around on this one for sure.
The proper way to do this, of course, would be via something like an
"around" method applied to the callback. Since that's not a
possibility, the correct thing is still to wrap a ring buffer
management layer around the jack buffer processing, but all inside the
callback routine itself.
Frank
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
