Re: [Discuss-gnuradio] Gnuradio locking up

[Josh Blum]

On 11/22/2011 08:28 AM, Philip Balister wrote:
> On 11/22/2011 11:02 AM, Rachel Kroll wrote:
>>
>> On Nov 22, 2011, at 7:56 AM, Marcus D. Leech wrote:
>>
>>> On 22/11/11 10:48 AM, Rachel Kroll wrote:
>>>> It's pretty easy to get wedged forever if you call lock and unlock a lot 
>>>> in conjunction with connect and disconnect.  Sooner or later, you'll hit a 
>>>> race and things will get stuck.
>>>>
>>>> I have a simple reproduction case if anyone is interested.  It'll hang 
>>>> reliably after a few dozen iterations.
>>>>
>>>>
>>> That's the type of information that shouldn't be withheld from this
>>> list, and by implication, the
>>>  developers.  Don't assume that because you've found a
>>> bug/unexpected-behaviour, that the developers
>>>  know about it, and are working on a fix.
>>
>> It's come up a few times in the mailing list archives.  The usual solution 
>> seems to be "add more sleeps", which of course is not a fix.
>>
>> Anyway, here's the reproduction case:
>>
> 
> How do you compile this? I put it in a file and made a couple fo quick
> stabs at it.
> 
>> #include <gnuradio/gr_file_sink.h>
> 
> This raises a question, the standard search paths find this file, but
> the gnuradio headers have lines like:
> 
> #include <gr_core_api.h>
> 
> which force you to add -I/usr/local/include/gnuradio to the compile
> command. I don't like mixing my include styles and feel searching both
> paths can lead to problems.
> 

If you look at the pc file, the intention was to manually specify the
include path: -I/usr/local/include/gnuradio This is a fairly common
paradigm. I like the way we handle gruel better, but in any case, I'd
recommend keeping the coding style aligned with the manufacturer's
style. You will also find that many gr headers that include one another
depend on the headers being in this "flat" search space.

-Josh