[Discuss-gnuradio] gr_file_descriptor_source blocking

[Nico Otterbach]

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 :

(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<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
#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<void> >::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