[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