On 04/05/2012 07:08 AM, Tom Rondeau wrote: > On Mon, Apr 2, 2012 at 11:10 PM, Josh Blum <[email protected]> wrote: >> >>> I hope this clears up why the PMT read/write issue is a non-starter. >>> I'd rather see a bit of slowdown then segfaults :) >>> >> >> I'm not sure what segfaults you are referring to. But the thread safety >> issue is already a problem. Technically, tags/PMTs are one giant race >> condition if your downstream blocks do not follow the implicit contract. >> We should fix this. >> >> -Josh > > Tags are PMTs and write-once, read-only objects. To change them, you > have to create a new tag. This is what's done for the sample number > value when going through rate change blocks. We instantiate a new PMT > with the new value. Since they are read-only and this is handled in > the block executor, there is no problem. Even if we change the PMT of > a tag for the number of samples, anyone holding a reference to the PMT > at the time will still have that PMT until it goes out of scope. > > The only issue with thread safety are those PMTs that are read/write > (like vectors, and we don't use them in the tags), and we are going to > fix them.
That sounds like a lot more of a complicated change than the pmt_const_t. What did you have in mind for the "fix"? There's no need for a pmt_const class because all PMTs are > constant. We're not going to introduce more writable shared memory > objects between blocks to exacerbate the problem. > This is email is totally bonkers. I am going to have to issue "the PMT Challenge". Please wait for another thread and challenge details. -josh _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
