discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Possibly incorrect gr_msg_queue.delete_head_nowai


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Possibly incorrect gr_msg_queue.delete_head_nowait() implementation
Date: Fri, 04 Oct 2013 01:03:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Hi Isdren,

I believe the correct implementation should the 'return 0' line uncommented and 
the 'return gr_message_sprt()' removed.

That would not compile, since you can't convert int to boost::shared_ptr.
What you see in your python output are really only the swig wrappers of these 
shared pointers including their memory address, not the address they points at.
So yes, if you use a _nowait() method, you usually have to check its output; 
that's the price you pay for not waiting as long as it takes to produce your 
return value.

As far as I know, there is no way to check the address that a shared_ptr points 
add from within python; I'm not quite sure there is an easy way to fix this. 
Swig just doesn't work like that, and extending boost::shared_ptr doesn't sound 
very sensible.
I guess a logical way would be to have a c++ implementation of the equality comparison operator 
that takes two boost::shared_ptr<gr::message> . That would make it possible to check 
wether a sptr actually points to an object or is a nullpointer from python. However, that'd be 
a really "ugly" thing from a syntax point of view:

p2 = q.delete_head_nowait()
p_ref = gr.message_sptr()
if not gr.message.sptr_equals(p2,p_ref):
    print p2.to_string()

You further wrote:
>This should have been obvious to me earlier. The problem is that 0 _is_ being 
return and the assertion that 'px != 0' (correctly) fails. Perhaps the use of 
gr.msg_queue.delete_head_nowait() should be deprecated and the equivalent behavior 
achieved by checking if gr.msg_queue.count() == 0 prior to calling 
gr.msg_queue.delete_head().

I strongly disagree - the delete_nowait_method has it's uses and is part of the 
standard scheduler; it's generally a good idea to have a non-blocking pop for a 
mutexed queue, otherwise it can be really hard to avoid deadlock conditions.
Since your "if gr.msg_queue.count() == 0: p2 =gr.msg_queue.delete_head()" is 
not atomic, it would not even fix the issue - someone else might still be stealing your 
last queue element between your check and your delete_head().

Greetings,
Marcus




reply via email to

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