Push source blocking on data

Hi - I’m debugging a problem with cleaning up a pipeline which is hanging, I think because the zmqsrc element is blocking on a ZeroMQ message that never arrives, like this

static GstFlowReturn
gst_zmq_src_create (GstPushSrc * psrc, GstBuffer ** outbuf)
{
....
  while (1) {
    rc = zmq_msg_recv (&msg, src->socket, 0);
    ... 
  }
...

Is this reasonable behaviour for a push source? I’m guessing not, but ideally how should such a source handle waiting for data that may never come, without jamming up the system?

Yes, you need some way to interrupt the blocking receive/wait (usually you do that by implementing the unlock function and doing something that wakes up your streaming thread there).

It will depend on what APIs are available on the zmq side for this.

As a quick hack you could pass ZMQ_DONTWAIT to zmq_msg_recv(), and then sleep for a short time before you try again (and of course every time you wake up you can check if you’re supposed to shut down or not). That has a lot of overhead though.

A slightly better way might be to use zmq_poll() with a timeout. That way you can always handle messages as soon as they arrive, but you will never wait forever. Then the shutdown will just be delayed by up to whatever your timeout is.

Ideally there’d be some kind of poll or receive that you can unblock in some way (or a poll on multiple things where one of them is a wakeup fd you can signal or somesuch).

You’ll have to check the zmq APIs. There must be something.

(I guess you can’t just send yourself a message from another thread?)

Thanks, what’s a good example of using unlock in this way?

gst_fd_src_unlock() in fdsrc or gst_udpsrc_unlock() in udpsrc perhaps, but those are really tied closely to how the APIs used work.