[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Recent development activity, upcoming plans
From: |
Josh Blum |
Subject: |
Re: [Discuss-gnuradio] Recent development activity, upcoming plans |
Date: |
Thu, 05 Apr 2012 12:09:29 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 |
On 04/05/2012 07:08 AM, Tom Rondeau wrote:
> On Mon, Apr 2, 2012 at 11:10 PM, Josh Blum <address@hidden> 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