[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: A Question About Gnuradio OOT Block Startup, Sleeping the Block
From:       Jeff Long <willcode4 () gmail ! com>
Date:       2022-12-15 13:35:49
Message-ID: CAC5f9jbyqYt_ydWjthzxU63UW1vnFgvaatHWuDsi-vX0U9s=-Q () mail ! gmail ! com
[Download RAW message or body]

If your block is purely a message source, override start() and have it set
an flag, e.g., a pthreads condition or Python threading.Event. The message
generation portion (thread?) of your block should wait on the flag before
sending anything.

Otherwise, you would be sending messages out in response to work() or
handle_msg() calls, which won't happen until the runtime is up and working.

On Thu, Dec 15, 2022 at 7:41 AM Brian Brown <22brianbrown@gmail.com> wrote:

> Hi!
>
> I am designing a message in-out OOT block that has a similar structure to
> the Message Strobe. It is ought to send packets as soon as the Gnuradio
> runtime permits. I realized that it is necessary to sleep the block off of
> any work for a short period of time to surpass the "block::start();"
> initialization. Otherwise, I am assuming, the thread is rushing an output
> before the Gnuradio scheduler initialization is settled therefore is
> breaking the runtime and forcing an exit. For now I am sleeping the block
> to solve the issue for an arbitrary duration, say 1000 ms. I was wondering
> if there is a recommended sleep duration, block specific or in general that
> is fixed to all blocks or calculable. Or is there a solid work around to
> sleeping the thread at all. I have looked for an explanation online and
> searched through the archives but could not find an answer. Any help would
> be appreciated.
>
> Thanks in advance!
> Brian.
>

[Attachment #3 (text/html)]

<div dir="ltr">If your block is purely a message source, override start() and have it \
set an flag, e.g., a pthreads condition or Python threading.Event. The message \
generation portion (thread?) of your block should wait on the flag before sending \
anything.<div><br></div><div>Otherwise, you would be sending messages out in response \
to work() or handle_msg() calls,  which won&#39;t happen until the  runtime is up and \
working.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Thu, Dec 15, 2022 at 7:41 AM Brian Brown &lt;<a \
href="mailto:22brianbrown@gmail.com">22brianbrown@gmail.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>Hi!<br></div><div><br></div><div>I am designing a message in-out OOT  \
block that has a similar structure to the Message Strobe. It is ought to send packets \
as soon as the Gnuradio runtime permits. I realized that it is necessary  to sleep \
the block off of any work for a short period of time to surpass the \
&quot;<span>block::start</span>();&quot; initialization. Otherwise, I am assuming, \
the  thread is rushing an output before the Gnuradio scheduler initialization is \
settled therefore is breaking the runtime and forcing an exit. For now I am sleeping \
the block to solve the issue for an arbitrary duration, say 1000 ms. I was wondering \
if there is a  recommended sleep duration, block specific or in general that is fixed \
to all blocks or calculable. Or is there a solid work around to sleeping the thread \
at all.  I have looked for an explanation online and searched through the archives \
but could not find an answer. Any help would be \
appreciated.<br></div><div><br></div><div>Thanks in \
advance!</div><div>Brian.<br></div></div> </blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]