[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]