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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
