An alternative is to use none blocking IO and use poll or select in your
worker thread and use another fd created with pipe(2) to signal that you
are done... Or a timer fd like Sylvain suggests. Not sure if boost has some
portability wrapping for this?
--Albin
On Mon, Apr 13, 2020, 19:59 Sylvain
Hi Moses,
ah sorry, I was misreading your code!
Looking at this yes, classical socket programming problem:
Looks like your ListenLoop probably simply hangs on `accept`; that's
because the socket is in blocking mode by default.
So, you'd "simply" do the following:
1. prepare your socket as done
The m_finished thing only works if you're not using any blocking calls.
But you're using `accept` and `recv` etc ... all calls that can block
forever until they get something.
You need to use `select` on the file descriptors while waiting for
events / data and set a timeout on that select so your
Hi Marcus,
I was trying to emulate how the ZMQ block handles multithreading.
Basically, the ZMQ block overrides the stop() function and joins the
threads. This is the same thing I tried to do to stop the receive and
listen threads. Is there any other way of doing this?
bool
TCPServer::stop()
{
Hi Moses,
your code doesn't show how your GNU Radio block's stop() function would
tell your TCP Server thread that it's time to shut down, so I presume
that doesn't happen – that would explain why the flow graph can't ever
shut down!
Best regards,
Marcus
On 13.04.20 18:54, Moses Browne
Hello everyone,
I have created a TCP/IP block by adapting the ZMQ message pub block. Both
blocks make use of boost multithreading. The TCP/IP block is used by a
standalone C++ program. To run the gnuradio topblock, the C++ program calls
tb->start() function. To stop the topblock, the functions
