# Gr\_file\_descriptor\_source blocking

**URL:** <https://www.ruby-forum.com/t/gr-file-descriptor-source-blocking/228712>\
**Category:** GNU Radio\
**Created:** [May 4, 2013, 6:22pm UTC](https://www.ruby-forum.com/t/gr-file-descriptor-source-blocking/228712 "2013-05-04T18:22:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nico\_Otterbach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/82dd89/32.png) [@Nico\_Otterbach](https://www.ruby-forum.com/u/Nico_Otterbach)\
**Post date:** [May 4, 2013, 6:22pm UTC](https://www.ruby-forum.com/t/gr-file-descriptor-source-blocking/228712/1 "2013-05-04T18:22:34Z")

</div>

Hi all,

I just ran into a couple of problems concerning blocking calls and  
wanted to discuss possible solutions together with some gr-experts.

I’m trying to exchange samples between different flowgraphs on different  
computers over the network. Therefore I’m using the TCP blocks  
(grc\_blks2), which are actually using the gr\_file\_descriptor\_\*-blocks to  
access the created socket file descriptors.

The problem occurs almost every time I try to stop the tob block of a  
“relaying” (tcp\_source - do some processing - tcp\_sink) flowgraph in  
order to rebuild the whole flowgraph. It hangs up in the wait() method  
called right after stop(); leading to the assumption, that some  
thread(s) couldn’t be exited.

Here’s the relevant gdb output after calling the wait() method, you can  
find a more extensive one on [http://pastebin.com/1mtgi8jZ](http://pastebin.com/1mtgi8jZ) :

(gdb) t 57  
[Switching to thread 57 (Thread 0x7fff4dfeb700 (LWP 5839))]  
#0 0x00007ffff7bcbd2d in read () from  
/lib/x86\_64-linux-gnu/libpthread.so.0  
(gdb) bt  
#0 0x00007ffff7bcbd2d in read () from  
/lib/x86\_64-linux-gnu/libpthread.so.0  
#1 0x00007ffff41f3b24 in gr\_file\_descriptor\_source::read\_items(char\*,  
int) () from /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
#2 0x00007ffff41f3bc5 in gr\_file\_descriptor\_source::work(int,  
std::vector\<void const\*, std::allocator\<void const\*\> \>&,  
std::vector\<void\*, std::allocator\<void\*\> \>&) ()  
from /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
#3 0x00007ffff40eeb54 in gr\_sync\_block::general\_work(int,  
std::vector\<int, std::allocator \>&, std::vector\<void const\*,  
std::allocator\<void const\*\> \>&, std::vector\<void\*, std::allocator\<void\*\>

> &) ()  
> from /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
> #4 0x00007ffff40cd3a3 in gr\_block\_executor::run\_one\_iteration() () from  
> /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
> #5 0x00007ffff40fb347 in  
> gr\_tpb\_thread\_body::gr\_tpb\_thread\_body(boost::shared\_ptr\<gr\_block\>, int)  
> () from /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
> #6 0x00007ffff40ec1b6 in  
> boost::detail::function::void\_function\_obj\_invoker0\<gruel::thread\_body\_wrapper\<tpb\_container\>,  
> void\>::invoke(boost::detail::function::function\_buffer&) ()  
> from /usr/local/lib/libgnuradio-core-3.6.5git.so.0.0.0  
> #7 0x00007ffff3dea6be in  
> boost::detail::thread\_data\<boost::function0 \>::run() () from  
> /usr/local/lib/libgruel-3.6.5git.so.0.0.0  
> #8 0x00007ffff3483da9 in ?? () from /usr/lib/libboost\_thread.so.1.48.0  
> #9 0x00007ffff7bc4e9a in start\_thread () from  
> /lib/x86\_64-linux-gnu/libpthread.so.0  
> #10 0x00007ffff69b1ccd in clone () from /lib/x86\_64-linux-gnu/libc.so.6  
> #11 0x0000000000000000 in ?? ()

It looks like the gr\_file\_descriptor\_source is blocking, which seems to  
be correct if you take a look at the appropriate code section.

Is this (still) the expected behavior or did I make a mistake?  
If not, do you have any advice on how to smartly solve the problem  
without a rewrite? - Perhaps the blocking call could be a problem for  
other users, too.

Temporarily, I solved the problem by using the UDP blocks, whereby the  
implementation looks like “boost thread calls” were taken into account.  
However, this is not the preferred method because of the possible  
sample-loss.

Thanks,  
Nico

---

<div class="post-metadata">

**Author:** ![Nico\_Otterbach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/82dd89/32.png) [@Nico\_Otterbach](https://www.ruby-forum.com/u/Nico_Otterbach)\
**Post date:** [May 6, 2013, 4:02pm UTC](https://www.ruby-forum.com/t/gr-file-descriptor-source-blocking/228712/2 "2013-05-06T16:02:34Z")

</div>

On Sat, May 4, 2013 at 12:21 PM, Nico Otterbach  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> The problem occurs almost every time I try to stop the tob block of a  
> #0 0x00007ffff7bcbd2d in read () from /lib/x86\_64-linux-gnu/libpthread.so.0
> 
> > &, std::vector\<void\*, std::allocator\<void\*\> \>&) ()  
> > #7 0x00007ffff3dea6be in boost::detail::thread\_data\<boost::function0
> 
> Thanks,  
> Nico

Nico,

Yes, the ‘read’ function is a blocking call that doesn’t exit when the  
SIGINT signal is sent when you say ‘stop()’. In the UDP blocks that  
were redone with Boost ASIO, that was partly done to make the block  
(more easily) compatible on more OSes as well as to use the asynch  
receive code for easy interruption.

For the file\_descriptor\_source, you’ll want to implement the use of  
‘select’ to better handle this.

Tom